Is this monomorphism?



  • Some lovely perl code I inherited. This might seem like a minor offense, but I've got 50K lines of code written by this guy and it is all this ugly. 

    sub fexists {
            my $fil = shift;
            if(-e $fil) {
                    return 1;
            }
            return 0;
    }



  • Too much time on your hands ? Write wrapper subs !!



  • I don't know PERL.  If I did know PERL, I wouldn't know PERL, because ultimately, PERL is unknowable.

    Just so you know: all PERL code is ugly.



  • @jigjig said:

    Some lovely perl code I inherited. This might seem like a minor offense, but I've got 50K lines of code written by this guy and it is all this ugly. 

    sub fexists {
            my $fil = shift;
            if(-e $fil) {
                    return 1;
            }
            return 0;
    }

    That looks to me like someone who can't remember the -e operator.  Please tell me there are subs called ismatch, replace, and transpose!



  • @mrprogguy said:

    Just so you know: all PERL code is ugly.

     Depends who's writing it...



  • @jigjig said:

    Some lovely perl code I inherited. This might seem like a minor offense, but I've got 50K lines of code written by this guy and it is all this ugly. 

    sub fexists {
            my $fil = shift;
            if(-e $fil) {
                    return 1;
            }
            return 0;
    }

    Is this in perl::wheresThatFuckingCamelBook ?



  • That code is way too long to be good perl code, it should have been:

    [code]sub fexists { -e $_[0] }[/code]




  • @jigjig said:

    Some lovely perl code I inherited. This might seem like a minor offense, but I've got 50K lines of code written by this guy and it is all this ugly. 

    sub fexists {
            my $fil = shift;
            if(-e $fil) {
                    return 1;
            }
            return 0;
    }

     

    Shiny!  Has this person come from a different language/environment background?  It almost strikes me like the people that in C would have done

    #define BEGIN {
    #define END }



  • @mrprogguy said:

    I don't know PERL.  If I did know PERL, I wouldn't know PERL, because ultimately, PERL is unknowable.

    Well, it seems that this function does something that is pretty basic, and could be implemented by replacing all instances of fexists($whatever) with (-e $whatever), thus eliminating the function entirely.  Why write a function if there is already a sufficient operator to do the job, especially if the operator is invoked by the function, as is the case here.

    That said, a better form of the function, if you really must have it, would be:

    sub fexists
    {
        return (-e shift());
    }

    If you want to make it a tad more self-documenting, you could do this:

    sub file_exists
    {
        my $file = shift();
        my $result;
        $result = (-e $file);
        return ($result);

    Note how the name of the function was changed to make it more legible. 

    Just so you know: all PERL code is ugly.

    I disagree.  Look at my examples and tell me why they are ugly.

     



  • @Starfish said:

    That code is way too long to be good perl code, it should have been:

    [code]sub fexists { -e $_[0] }[/code]


    It's lines like this which confirm Perl to be non-intuitive despite its utility.  Basically, reading Perl requires that you study (or have memorized) its list of built-in operators and syntax; there's no way you could "derive" how it works from simply looking at the code (assuming the lack of helpful symbolic names, like the one above).  Granted, that latter isn't a case for all high level languages, but generally you can still determine what C is doing without having to resort to reference (yes, you can make C look horrible if you want), and things like Pascal are even more difficult (now an obfuscated Pascal contest... that would be interesting!) (Perhaps this is just a side effect of C having contextually helpful library function names and keywords... you could easily make a function in C called e() which takes a file argument and returns a value indicating if the file exists or not....)

    I guess in my mind code is not simply to give instructions to computers but also instructions to other humans on what those instructions are (note the subtle difference from my arguments against human-readable document formats, in which most of the information people store in document formats is not instructions for humans or clues to what the instructions are). 



  • @Critter said:

    @mrprogguy said:

    I don't know PERL.  If I did know PERL, I wouldn't know PERL, because ultimately, PERL is unknowable.

    Well, it seems that this function does something that is pretty basic, and could be implemented by replacing all instances of fexists($whatever) with (-e $whatever), thus eliminating the function entirely.  Why write a function if there is already a sufficient operator to do the job, especially if the operator is invoked by the function, as is the case here.

    That said, a better form of the function, if you really must have it, would be:

    sub fexists
    {
        return (-e shift());
    }

    If you want to make it a tad more self-documenting, you could do this:

    sub file_exists
    {
        my $file = shift();
        my $result;
        $result = (-e $file);
        return ($result);

    Note how the name of the function was changed to make it more legible. 

    Just so you know: all PERL code is ugly.

    I disagree.  Look at my examples and tell me why they are ugly.

     

    I love perl, but both of these come to mind as ugly for a programming language

    •  using shift() to access parameters. And there isn't a pretty way to to do it
    •  -e

     

     



  • You can use the @_ array to access sub params if you like, the shift(); is just for brevity purposes, as are the -e, -f, -d, ... switches.

    Granted, it would be "prettier" if you could do sub doSomething (my $param1, my $param2), but that is a bit too verbose for perl standards :)
     



  • @too_many_usernames said:

    @Starfish said:

    That code is way too long to be good perl code, it should have been:

    [code]sub fexists { -e $[0] }[/code]


    It's lines like this which confirm Perl to be non-intuitive despite its utility.  Basically, reading Perl requires that you study (or have memorized) its list of built-in operators and syntax; there's no way you could "derive" how it works from simply looking at the code (assuming the lack of helpful symbolic names, like the one above).  Granted, that latter isn't a case for all high level languages, but generally you can still determine what C is doing without having to resort to reference (yes, you can make C look horrible if you want), and things like Pascal are even more difficult (now an obfuscated Pascal contest... that would be interesting!) (Perhaps this is just a side effect of C having contextually helpful library function names and keywords... you could easily make a function in C called e() which takes a file argument and returns a value indicating if the file exists or not....)

    I guess in my mind code is not simply to give instructions to computers but also instructions to other humans on what those instructions are (note the subtle difference from my arguments against human-readable document formats, in which most of the information people store in document formats is not instructions for humans or clues to what the instructions are). 


    It's not as bad as you make it out to be. Especially not this example. No one with any real perl experience is going to a reference guide to look up @, and while I've gone years without having to use or remember the file tests, they are unique enough that I know exactly where I need to go to look them up.  It's certainly much less work to understand the intricacies of sub fexists { -e $_[0] } than the equivalent C code.

    Perl is ugly in syntax and implementation, but it is beautiful in elegance and versatility. It asks a lot from it's users for a scripting language, but it gives them back a lot as well. That freedom can be used for good or evil, and sometimes must be used for both.
     



  • Every function call, class method call and instance method call gets arguments the same way: The array named _. If you simply don't know any Perl at all, yes, it's frequently easy not to know what's going on. (Okay; prototypes change this, but the use of them is not recommended and not really idiomatic.)

    However, receiving arguments is almost totally idiomatic in code on CPAN: It's "my ($a, $b, $c) = @_;" or "my $a = shift". There's an infrequent exception of taking a list or dictionary of something in the parameters, and then the arguments are still just a freaking array that you turn into whatever you need.

    (The first module I came to is http://search.cpan.org/src/MEWSOFT/Religion-Islam-PrayerTimes-1.02/lib/Religion/Islam/PrayerTimes.pm which is basically just as I described.)

     



  • @Critter said:

    @mrprogguy said:

    I don't know PERL.  If I did know PERL, I wouldn't know PERL, because ultimately, PERL is unknowable.

    Well, it seems that this function does something that is pretty basic, and could be implemented by replacing all instances of fexists($whatever) with (-e $whatever), thus eliminating the function entirely.  Why write a function if there is already a sufficient operator to do the job, especially if the operator is invoked by the function, as is the case here.

    That said, a better form of the function, if you really must have it, would be:

    sub fexists
    {
        return (-e shift());
    }

    If you want to make it a tad more self-documenting, you could do this:

    sub file_exists
    {
        my $file = shift();
        my $result;
        $result = (-e $file);
        return ($result);

    Note how the name of the function was changed to make it more legible. 

    Just so you know: all PERL code is ugly.

    I disagree.  Look at my examples and tell me why they are ugly.

     

    Elementary, my dear Watson:  they're in Perl.



  • @quamaretto said:

    Every function call, class method call and instance method call gets arguments the same way: The array named . If you simply don't know any Perl at all, yes, it's frequently easy not to know what's going on. (Okay; prototypes change this, but the use of them is not recommended and not really idiomatic.)

    However, receiving arguments is almost totally idiomatic in code on CPAN: It's "my ($a, $b, $c) = @;" or "my $a = shift". There's an infrequent exception of taking a list or dictionary of something in the parameters, and then the arguments are still just a freaking array that you turn into whatever you need.

    (The first module I came to is http://search.cpan.org/src/MEWSOFT/Religion-Islam-PrayerTimes-1.02/lib/Religion/Islam/PrayerTimes.pm which is basically just as I described.)

     


    The problem I have isn't with the parameter passing; that's about the only thing that is easily determinable by "just looking at Perl".  Of course, I still can't tell just from looking what the difference between $ and @ is (Yes, I know these are easily looked up).  The bigger problem I have is with the '-e' bit.  Sure, given the context of a function 'fexists' then I assumed that token is something like an "exists" operator.  However, the problem is lack of context.  I'm not sure I can see why a C equivalent would be more difficult; it would probably just look like if (exists(param0)) or something like that - with a helpful name.

    I'm not nocking the fact that there are certain things (like -e) that are known to those familiar with the language, nor am I saying that C or whatever is always obvious (things like *buf[0]->ref are especially fun grin ).  But generally speaking, "high level" functions in other languages have names with more information than a single character like 'e'.



  • Hmm... -e is an operator, not a function. The guy could have created the function so that he could use it in later HOFs, but probably not. :)

    I agree that the -e thing is weird. I personally think that Larry should have made an effort to eliminate every conceivable feature of Perl 5 that would leave a recognizable language, rather than throwing it away to make Perl 6. (This is somewhat the aim of use strict; but that won't eliminate any operators.)

     



  • @obediah said:

    I love perl, but both of these come to mind as ugly for a programming language

    •  -e

    You do realise that the file operators are directly copied from /usr/bin/test, right? Perl contains several features that are shell constructs, on the basis that you should be able to rewrite any shell script into perl without having to make major changes. You don't have to use them.



  • @too_many_usernames said:

    @Starfish said:

    That code is way too long to be good perl code, it should have been:

    [code]sub fexists { -e $_[0] }[/code]


    It's lines like this which confirm Perl to be non-intuitive despite its utility.

    Larry would say that no language is, or should attempt to be, "intuitive".

     

    Basically, reading Perl requires that you study (or have memorized) its list of built-in operators and syntax; there's no way you could "derive" how it works from simply looking at the code (assuming the lack of helpful symbolic names, like the one above).

    Perl is fundamentally based on linguistic principles - not computer science, but real linguistics for real human languages. Every human language requires that you study or have memorized its basic vocabulary; you are completely incapable of comprehending it otherwise, and it's almost impossible to derive how it works from simply looking at it. It should not be surprising that Perl behaves the same way.

     

    I guess in my mind code is not simply to give instructions to computers but also instructions to other humans on what those instructions are. 

    And Perl is designed from the ground up to optimise this process, for people who understand Perl. People who don't understand Perl have no more business trying to read it than all those Americans who go to Japan, wave their arms and shout at the natives in English, and then complain about how nobody there can talk properly.



  • @asuffield said:

    And Perl is designed from the ground up to optimise this process, for people who understand Perl. People who don't understand Perl have no more business trying to read it than all those Americans who go to Japan, wave their arms and shout at the natives in English, and then complain about how nobody there can talk properly.

    Aha!  Finally someone has hit on what I was driving at - I've been in a bit of a funk lately I guess.

    Interesting similarities there - just as people get all "nationalistic" when it comes to their spoken language, it's not surprising that the same thing happens in computer languages as well.



  • @asuffield said:

    @obediah said:

    I love perl, but both of these come to mind as ugly for a programming language

    •  -e

    You do realise that the file operators are directly copied from /usr/bin/test, right? Perl contains several features that are shell constructs, on the basis that you should be able to rewrite any shell script into perl without having to make major changes. You don't have to use them.

    Whoa, point your lance somewhere else buster. I do realize where the file operators come from, and why they are there - but that doesn't mean they aren't ugly - and that is all I accused them of being.

    You are spot on with your statements about perl being for people that understand perl.  Python users are quick to chastise perl for the overhead of having multiple ways to skin a cat, but in many of those cases the methods actually are different and not just syntactic sugar. Where python would say you can skin a cat with a knife, so adding other methods would just make the language hard to learn,  perl acknowledges that sometimes you may need to skin a live tiger, so it gives you a rifle as well.
     

     



  • @asuffield said:

    Perl is fundamentally based on linguistic principles - not computer science, but real linguistics for real human languages.


    That's the part I like.  The Perl I don't like is where they decided to make it very Unix-y and have all these weird special cases.



  • Must our designed languages inherit the flaws of the evolved ones?



  • @ahnfelt said:

    Must our designed languages inherit the flaws of the evolved ones?

    It is the only way to utilise the parts of our brains that are uniquely specialised to handle those languages. It's somewhat like programming a coprocessor. 



  • @asuffield said:

    @ahnfelt said:

    Must our designed languages inherit the flaws of the evolved ones?

    It is the only way to utilise the parts of our brains that are uniquely specialised to handle those languages. It's somewhat like programming a coprocessor. 

    But you wouldn't program your coprocessor to do a database lookup. Programming languages and human languages are used for fundamentally different things. There are other parts of your brain that you should utilize if you're programming, not how you speak with your neighbor.



  • @PSWorx said:

    @asuffield said:

    @ahnfelt said:

    Must our designed languages inherit the flaws of the evolved ones?

    It is the only way to utilise the parts of our brains that are uniquely specialised to handle those languages. It's somewhat like programming a coprocessor. 

    But you wouldn't program your coprocessor to do a database lookup. Programming languages and human languages are used for fundamentally different things.

    The assumption behind the design of Perl is that programming languages are first and foremost explaining the algorithm to the next person to maintain it, and to yourself six months later when you've forgotten what you did. Also explaining the algorithm to the computer is a far simpler problem which is treated as a secondary goal.

    Perl is a human language first, and a programming language second. 



  • @too_many_usernames said:

    I'm not sure I can see why a C equivalent would be more difficult; it would probably just look like if (exists(param0)) or something like that - with a helpful name.

    BZZZT! Wrong. The standard way to do this in C is in fact

    #include <sys/types.h>
    #include <sys/stat.h>
    #include <unistd.h>
    
    int exists(const char* filename)
    {
        struct stat buf;
        if (stat(filename, &buf) != 0) {
            return 0;
        }
        return 1;
    }

    Yeah, I love intuitive names like "stat".

    And this is simplifying matters somewhat, as the stat() call may fail for other reasons than the file not existing. To be sure that we have a bona-fide case of a file not existing, we would need to check whether the value of errno is ENOENT or not. How intuitive!

    Yes, there [i]are[/i] languages that have better-designed libraries than Perl, but I honestly think it's a bit rich for you to pick C of all languages for your example. :)



  • @sinistral said:

    It almost strikes me like the people that in C would have done

    #define BEGIN {
    #define END }

     You jest, but /usr/src/cmd/sh/mac.h



  • @obediah said:

    •  using shift() to access parameters. And there isn't a pretty way to to do it

     Surely you don't think

    sub foo {
        my ($bar, $baz) = @_;
    ...

    is that bad, do you?



  • @Random832 said:

    @sinistral said:

    It almost strikes me like the people that in C would have done

    #define BEGIN {
    #define END }

     You jest, but /usr/src/cmd/sh/mac.h

    ... The universe is winning. 



  • @dhromed said:

    @Random832 said:

    @sinistral said:

    It almost strikes me like the people that in C would have done

    #define BEGIN {
    #define END }

     You jest, but /usr/src/cmd/sh/mac.h

    ... The universe is winning. 

    Yeah, it does tend to do that.

     

    From time to time.

    At least, most of the time, it's fun to watch! 



  • @asuffield said:

    And Perl is designed from the ground up to optimise this process, for people who understand Perl. People who don't understand Perl have no more business trying to read it than all those Americans who go to Japan, wave their arms and shout at the natives in English, and then complain about how nobody there can talk properly.

    Could you be any more conceited or elitist?  What a ridiculous pair of fallacious statements.



  • @operagost said:

    @asuffield said:

    And Perl is designed from the ground up to optimise this process, for people who understand Perl. People who don't understand Perl have no more business trying to read it than all those Americans who go to Japan, wave their arms and shout at the natives in English, and then complain about how nobody there can talk properly.

    Could you be any more conceited or elitist?  What a ridiculous pair of fallacious statements.

    Your father smells of elderberries and you don't appear to have a point. 



  • @obediah said:

    •  using shift() to access parameters. And there isn't a pretty way to to do it


    shift() is quite elegant if the function's parameters are a list of items to operate on -- but in that case, you might be better off using map() and an anonymous function.  Otherwise, you're probably better off using the "my ($a, $b, $c) = @_" form or using named parameters.


Log in to reply