«

I like perl. I've reading about python lately, which I found a little
annoying, and, today, I picked up Learning Perl and read a few
chapters. I like it. I think python is perhaps intended for someone
who hadn't programmed before, although, personally, I think it
somewhat fails at that. Perl, on the other hand, for someone who likes
shell, grep and awk, like I do, seems intuitive.

I also like the versatility of the syntax. That said, although it's
versatile, it also seemed consistent.

Python just annoyed me a little. It was just inconsistent.

On Apr 29, 8:12 pm, fli...@gmail.com wrote:
> I like perl.
So do I.

On Apr 29, 11:12 am, fli...@gmail.com wrote:
> I like perl. I've reading about python lately, which I found a little
> annoying, and, today, I picked up Learning Perl and read a few

I find pantyhose annoying.

> chapters. I like it. I think python is perhaps intended for someone
> who hadn't programmed before, although, personally, I think it
> somewhat fails at that. Perl, on the other hand, for someone who likes
> shell, grep and awk, like I do, seems intuitive.
>

This depends on how you view Perl. Perl can be viewed as either
Procedural or Object Oriented.
..
> I also like the versatility of the syntax. That said, although it's
> versatile, it also seemed consistent.
>

Versalitily isn't always a good thing. This might be stretching the
realms of funky Perl code, but consider the following two programs
that will add two numbers.

#!/usr/bin/perl -w

sub modify{
my $value = $_[0] + $_[1];
print "$value \n";
}

my $x = 5;
my $y = 7;

modify(5,7);

and

#!/usr/bin/perl -w

sub modify{
my $first=shift;
my $second=shift;
my $value = $first + $second;
print "$value \n";
}

my $x = 5;
my $y = 7;

modify(5,7);

> Python just annoyed me a little. It was just inconsistent.

In the end, all programming languages are just fagged up versions of
Lisp. Don't believe it? The following URL makes from some intresting
late night reading

http://www.paulgraham.com/icad.html

On Apr 29, 11:12 am, fli...@gmail.com wrote:
> I like perl. I've reading about python lately, which I found a little
> annoying, and, today, I picked up Learning Perl and read a few

I find pantyhose annoying.

> chapters. I like it. I think python is perhaps intended for someone
> who hadn't programmed before, although, personally, I think it
> somewhat fails at that. Perl, on the other hand, for someone who likes
> shell, grep and awk, like I do, seems intuitive.
>

This depends on how you view Perl. Perl can be viewed as either
Procedural or Object Oriented paradigm

> I also like the versatility of the syntax. That said, although it's
> versatile, it also seemed consistent.
>
Versatility isn't always a good thing. Sometimes this can lead to
stuff being inconsistent. Consider the following code I duped from a
Google search -).

#!/usr/bin/perl -w

use strict;

sub alter ($) {
$_[0]= $_[0] . " blub";

}

my $s= "bla";

print "string before: $s \n";
alter( $s );
print "string after: $s\n";

[cdalten@localhost ~]$ ./alter.pl
string before: bla
string after: bla blub

vs

#!/usr/bin/perl -w

use strict;

sub alter ($) {
my $string = shift;
$string = $string . " blub";
}

my $s= "bla";

print "string before: $s \n";
alter( $s );
print "string after: $s\n";

[cdalten@localhost ~]$ ./alter.pl
string before: bla
string after: bla

> Python just annoyed me a little. It was just inconsistent.

In the end, all programming languages are just fagged up versions of
Lisp. Don't believe it? The following URL makes from some interesting
late night reading

http://www.paulgraham.com/icad.html


Chad

On 29 Apr 2007 22:08:41 -0700,
grocery_stocker <> wrote:

> Versatility isn't always a good thing. Sometimes this can lead to
> stuff being inconsistent. Consider the following code I duped from a
> Google search -).
> #!/usr/bin/perl -w

> sub alter ($) {
> $_[0]= $_[0] . " blub";
>
> }

> sub alter ($) {
> my $string = shift;
> $string = $string . " blub";
> }

I wouldn't call that inconsistent. I can understand that some people
find it unexpected -- and I could come up with other description for the
behaviour -- but it's not inconsistent for the following two reasons:

1 - The code is different, and alters different variables, so there is
no consistency to violate. The code is not consistent, so there is
no need for perl to behave in an identical, or even similar, way.

2 - It's documented to work this way (in perlsub).

The @_ array is 'magical' in subroutines, and its elements are aliased
to the scalar parameters to the subroutine call.

In the second subroutine, you create a lexically scoped local variable,
which you initialise by copying the contents of the first element of the
@_ array.


Note that this sort of aliasing behaviour occurs in only a few places,
and is documented that way. If you get surprised by it, get in the habit
never to modify variables unless you know they're local, or you intend
to modify a global variable.

Whether it's elegant/desirable for @_ to be aliased this way is a
separate discussion. For now, we're stuck with it.

Martien
--
|
Martien Verbruggen | Freudian slip: when you say one thing but
| mean your mother.
|

On 29 Apr 2007 21:29:54 -0700, grocery_stocker <>
wrote:

>Versalitily isn't always a good thing. This might be stretching the
>realms of funky Perl code, but consider the following two programs
>that will add two numbers.

Well, you're right. However there's a remark I always feel like making
when speaking of Perl's TMTOWTDIness: it's true that there's more than
one way to do it. But it's also true that for common situations there
is often a preferred way to do it. Or a few preferred ways, with
different advantages in different respects. So, if you have e.g. to
iterate over a range of numbers "the" WTDI is

for ($MIN..$MAX) { # ...

and if you have to iterate over a handle, then "the" WTDI is

while (<$fh>) { # ...

Please take all this with a grain of salt, of course.

Perl 6 aims at being even more multiparadigmatic than 5, and to stay
at the same time consistent. So thanks to lazy evaluation, you will
e.g. both

.say for 1..6; # and
.say for $fh;

>sub modify{
> my $value = $_[0] + $_[1];
> print "$value \n";

BTW: what is it, with that space?

>sub modify{
> my $first=shift;
> my $second=shift;
> my $value = $first + $second;
> print "$value \n";

These are perfectly equivalent. Both have probably a mischosen name,
since they do not modify anything, but add and print two numbers. The
former, for such an easy task, is probably preferable. But in that
case I would avoid the $value variable altogether.

Since I mentioned Perl 6 above, in it eventually we will have more
convenient ways and less ambiguity in passing parameters. We will
still be able to use @_ & C. but who does really need them when you
can do

sub addprint ($n,$m) { say $n+$m } # ?

(And you would add type declarations for $n and $m if you want to keep
safe for cheap.)


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

>>>>> "MD" == Michele Dondi <> writes:

MD> Well, you're right. However there's a remark I always feel
MD> like making when speaking of Perl's TMTOWTDIness: it's true
MD> that there's more than one way to do it. But it's also true
MD> that for common situations there is often a preferred way to
MD> do it. Or a few preferred ways, with different advantages in
MD> different respects.

More concisely: TMTOWTDI, but some ways are better than others.

Charlton


--
Charlton Wilbur

On 29 Apr 2007 22:08:41 -0700, grocery_stocker <>
wrote:

>This depends on how you view Perl. Perl can be viewed as either
>Procedural or Object Oriented paradigm

Perl can be viewed as a multiparadigmatic language supporting amongst
others procedural and object oriented paradigms. It has always been,
it's become more, it will be even more.

Now, Perl's current OO model is both weak, due to it being an
afterthought rather than a primary design choice, and charming for the
powerful and far reaching consequences it gets out of an extremely
simple structure constituted by a single "special" function and a tiny
bag of syntactic sugar. Perl 6's OO'ness will be pervasive but not
invasive: everything will be an object, but you won't be *forced* to
think of it as such.

>> I also like the versatility of the syntax. That said, although it's
>> versatile, it also seemed consistent.
>>
>Versatility isn't always a good thing. Sometimes this can lead to
>stuff being inconsistent. Consider the following code I duped from a
>Google search -).

>sub alter ($) {
> $_[0]= $_[0] . " blub";
>
>}

This is a well chosen name for a sub that spots a well documented
charachteristic of the special @_ array to actually modify a value.

>sub alter ($) {
> my $string = shift;
> $string = $string . " blub";
>}

This is an example of a sub with a badly chosen name for it uses a
different parameter passing mechanism that is similarly well
documented not to be usable to modify a value.

>> Python just annoyed me a little. It was just inconsistent.

Actually I would have thought it to be *more* consistent.

>In the end, all programming languages are just fagged up versions of
>Lisp. Don't believe it? The following URL makes from some interesting

Well, not really!

>late night reading
>
>http://www.paulgraham.com/icad.html

Indeed!


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Charlton Wilbur <> wrote:
>>>>>> "MD" == Michele Dondi <> writes:
>
> MD> Well, you're right. However there's a remark I always feel
> MD> like making when speaking of Perl's TMTOWTDIness: it's true
> MD> that there's more than one way to do it. But it's also true
> MD> that for common situations there is often a preferred way to
> MD> do it. Or a few preferred ways, with different advantages in
> MD> different respects.
>
> More concisely: TMTOWTDI, but some ways are better than others.


More humorously:

There are 9 ways to do the same thing in Perl, and 8 of them are no good!


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

On May 2, 1:23 pm, Michele Dondi <bik.m...@tiscalinet.it> wrote:
> On 29 Apr 2007 21:29:54 -0700, grocery_stocker <cdal...@gmail.com>
> wrote:
>
> >Versalitily isn't always a good thing. This might be stretching the
> >realms of funky Perl code, but consider the following two programs
> >that will add two numbers.
>
> Well, you're right. However there's a remark I always feel like making
> when speaking of Perl's TMTOWTDIness: it's true that there's more than
> one way to do it. But it's also true that for common situations there
> is often a preferred way to do it. Or a few preferred ways, with
> different advantages in different respects. So, if you have e.g. to
> iterate over a range of numbers "the" WTDI is
>
> for ($MIN..$MAX) { # ...
>
> and if you have to iterate over a handle, then "the" WTDI is
>
> while (<$fh>) { # ...
>
> Please take all this with a grain of salt, of course.
>
> Perl 6 aims at being even more multiparadigmatic than 5, and to stay
> at the same time consistent. So thanks to lazy evaluation, you will
> e.g. both
>
> .say for 1..6; # and
> .say for $fh;
>
> >sub modify{
> > my $value = $_[0] + $_[1];
> > print "$value \n";
>
> BTW: what is it, with that space?
>

Just a habit I've gotten into.