Re: Re: Re: Re: Re: Breaking output lines into N-element chunks

better read some Perl :)

Juerd thats a big load of hoo-hoo and you know it.

most occuring idioms,

Do a grep of site/lib and you'll see just how common that idiom is. I think youll be suprised.

Anyone who doesn't see it's a constant (single return value, empty prototype, name in ALLCAPS, defined before any other sub and often found in @EXPORT), should not be maintaining my code.

The fact is that these "constants" (they arent really so lets be careful with that term) will not behave as expected in about 5% of situations. And you've just demonstrated my point. You didnt even realize what quirks I meant. So if you didn't why the hell would the maintainence programmer? Oh and the other point is that you will almost never have the choice of who maintains your code.

If someone hires a non-coder to do code maintenance, that's not my problem :)

Actually, 99% of the time it will be your problem. It will be your problem when your boss fires you for writing unmaintainable code, itll be your problem when your boss tells you to drop the sexy new project you are working on to do maintainence on old code that has been written poorly, it will be your problem when you stop getting work because you have a reputation of writing unmaintainable code.

Unmaintable code is bad code. Its your job as a developer to anticipate _everything_ including the skill levels of those that come after you. Which you should expect to be lower than your own.

Frankly juerd im a little disappointed about your reply and I think that if you sit back and reconsider so will you.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Comment on Re: Re: Re: Re: Re: Breaking output lines into N-element chunks

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Breaking output lines into N-element chunks by Juerd (Abbot) on Apr 12, 2002 at 16:46 UTC
Do a grep of site/lib and you'll see just how common that idiom is. I think youll be suprised. I did grep my module directories and I am surprised. I am surprised that so many constants do exist :) `2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /sub\s+[A-Z_] ++\s\(\s\)/' * / //* /// \| wc -l 1094 # Sorry for the ugly /-stuff. I didn't feel like # using File::Find in a oneliner :)` [download] I think you might be surprised as well... `2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /use\sconsta +nt/' / //* /// \| wc -l 0` [download] In /usr/share/perl, you would be right. There are 47 use constants in my /usr/share/perl, and only 24 empty-prototype all-caps subroutines. The fact is that these "constants" (they arent really so lets be careful with that term) will not behave as expected in about 5% of situations. The constant pragma uses the exact same method, only in a more convoluted way. It's _ONLY_ syntax (or call it "style" if you think that's a more appropriate word). Out of constant.pm: `if (@_ == 1) { my $scalar = $_[0]; $full_name = sub () { $scalar }; } elsif (@_) { my @list = @_; $full_name = sub () { @list }; } else { $full_name = sub () { }; }` [download] As you can see, there's nothing wrong with the empty prototype sub. Its your job as a developer to anticipate _everything_ including the skill levels of those that come after you.* I refuse to. Perl has many nifty features, and I'm not going to avoid them just because my code might be maintained by someone without programming knowledge. Take regexes for example: how many people will understand regexes but not simple constant idioms? Do I have to avoid regexes because they're hard to read for beginning regex hackers? Must I not use map, because the majority of Perl beginners doesn't know how it works? Should programmers avoid object orientation in favor of PHP-like code (I don't know why, but beginners seem to like PHP's simplicity)? Do you mean we should write our own alternatives to pack and unpack just because we should anticipate _everything_? Sorry, but I find that a bit hard to accept. If I liked bondage like that, I would still be coding in BASIC, and I would have never used Perl's flexibility :). Frankly juerd im a little disappointed about your reply That was in no way my intention. I do however think you miss a great deal of Perl knowledge if you don't recognise the empty-prototype return-only constant idiom. I hope we both learned. Yes, I reinvent wheels.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: Re: Breaking output lines into N-element chunks
by Juerd (Abbot) on Apr 12, 2002 at 16:46 UTC

Do a grep of site/lib and you'll see just how common that idiom is. I think youll be suprised.

I did grep my module directories and I am surprised. I am surprised that so many constants do exist :)

2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /sub\s+[A-Z_]
++\s*\(\s*\)/' * */* */*/* */*/*/* | wc -l
   1094
# Sorry for the ugly */*-stuff. I didn't feel like
# using File::Find in a oneliner :)
[download]

2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /use\s*consta
+nt/' * */* */*/* */*/*/* | wc -l
      0
[download]

use

constant

The fact is that these "constants" (they arent really so lets be careful with that term) will not behave as expected in about 5% of situations.

The constant pragma uses the exact same method, only in a more convoluted way. It's _ONLY_ syntax (or call it "style" if you think that's a more appropriate word).
Out of constant.pm:

        if (@_ == 1) {
            my $scalar = $_[0];
            *$full_name = sub () { $scalar };
        } elsif (@_) {
            my @list = @_;
            *$full_name = sub () { @list };
        } else {
            *$full_name = sub () { };
        }
[download]

Its your job as a developer to anticipate _everything_ including the skill levels of those that come after you.

I refuse to. Perl has many nifty features, and I'm not going to avoid them just because my code might be maintained by someone without programming knowledge. Take regexes for example: how many people will understand regexes but not simple constant idioms? Do I have to avoid regexes because they're hard to read for beginning regex hackers? Must I not use map, because the majority of Perl beginners doesn't know how it works? Should programmers avoid object orientation in favor of PHP-like code (I don't know why, but beginners seem to like PHP's simplicity)? Do you mean we should write our own alternatives to pack and unpack just because we should anticipate _everything_?

Sorry, but I find that a bit hard to accept. If I liked bondage like that, I would still be coding in BASIC, and I would have never used Perl's flexibility :).

Frankly juerd im a little disappointed about your reply

That was in no way my intention. I do however think you miss a great deal of Perl knowledge if you don't recognise the empty-prototype return-only constant idiom. I hope we both learned.

Yes, I reinvent wheels.

[reply]
[d/l]
[select]