I find the perl syntax easier than python

[flifus]

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.

 

[tuser]

I like perl.

So do I.

 

[grocery_stocker]

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

 

[grocery_stocker]

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

 

[Martien verbruggen]

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

 

[Michele Dondi]

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

 

[Charlton Wilbur]

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

 

[Michele Dondi]

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.

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.

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

 

[Tad McClellan]

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!

 

[grocery_stocker]

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.

 

[Dr.Ruud]

Michele Dondi schreef:

grocery_stocker:

BTW: what is it, with that space?

RFC 2646

 

[Michele Dondi]

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

And this is an advantage? Limiting yourself to two arguments?

Well, you know perfectly well that this is an *artificial* example to
mimic the OP's one. But yes, it's there for those cases in which I
*do* want to limit myself to two arguments, and perhaps type check
them.

In Perl5, you aren't tempted to use named variables, so you get
your arguments in an array. And given an array, it's natural to

I can't believe you're implicitly assuming that those guys aren't
thinking of letting you do that in Perl 6 too, and more.

allow a variable number of arguments:

sub addprint {my $sum = 0; $sum += $_ for @_; print $sum, "\n"}

Funny, in Perl 6 that could be

sub addprint {say [+] @_}


Michele

 

[Michele Dondi]

So you do something like this

sub addprint (*@num) { say [+] @num };

D'Oh, you beat me. But in my example I showed our friend Abigail that
if you really want you still have @_.


Michele