To use things such as "ceil/floor", I need to "use POSIX"... Aren't they basic?

Group functions into modules/classes is a good thing. (Granted, "POSIX" is not a good grouping.)

In Python, you must do

import math
math.floor( x )
[download]

So why do you complain that the following is onerous?

use POSIX;
floor($x)
[download]

It is strongly recommended to "use strict" and make variables "my", then why it is not default?

It is in version 5.12 of the language.

Before 5.10, Perl didn't really have a way of specifying a minimum language version, so it was tied by backwards compatibility.

If in subroutine I can write "$_ = shift", why can't I write so in main (I need to write "$_ = shift @_").

A script's arguments are placed in @ARGV, so grabbing from there makes far more sense than grabbing from unpopulated @_ when outside of a sub.

Ruby's cho(m)p I like more, because I can proceed on string: gets.cho(m)p.split.do_smth...

1) chomp($foo); is more efficient than $foo = chomp($foo);.

2) chomp(@foo); is simpler than @foo = map chomp, @foo;.

Can't use blocks using "and/or":

Yes you can.

f() and do { ... };
[download]

"$hash{length}" it interpreted (length $_) as "length"

$hash{BAREWORD} is the same as $hash{'BAREWORD'}. Very useful. Making an exception for length would be bad (very error prone).

Surprise that "use bigint" doesn't DWIM in some cases.

Then you didn't read what it does. It promotes numerical constant literals to Math::BigInt objects.

Surprise was that ++ has magic (I need to know exceptions) and -- has not

I don't know if I'd say that "not treating abc as 0" is magic. As for --, I guess noone found a use for it.

Difficult exception is that "print (1+1)*2" != "print 2*(1+1)" == "print STDOUT (1+1)*2".

You're complaining about being given the option to omit parens around arguments. If you don't like being able to omit parens, then don't do it.

I think "print(..." should better wait until the end of block or ";".

Nonsense. You gotta be able to check the value print returns (e.g. print "foo\n" or die $!;).

Thanks for pointing me to the "normal" division in Python!

$ python
Python 2.7.3 (default, Feb 27 2014, 20:00:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 / 2
1
>>> 3.0 / 2
1.5
[download]

Indeed very attractive for me... 0.o

update

can't see a question, moved thread from SOPW to meditations where "opinions" belong to

A wise man once said:

To gain the benefits of Perl, programmers coming to it from a different language must learn and internalize idiomatic Perl programming style and technique. The same applies to programmers used to earlier and less expressive versions of Perl.

Thoughtlessly applying techniques effective in one language to another typically leads to awkward, poorly performing, and hard-to-maintain code. Such code is also most frustrating to write because every line of code and every compiler error message reminds the programmer that the language used differs from "the old language."

...except that he didn't say it quite like that. The statement above was written by Stroustrup, in The C++ Programming Language, 4th Edition.Except that everywhere you see Perl, his statement read "C++".

All of these bullet points enumerated in the top post of this thread are just annoyances or surprises to someone who comes to Perl from another language. And that entire class of issues pertains to anyone learning a new language when another language is more familiar. Such an individual will be frustrated until a similar comfort level is achieved in the new language.

For each of your bullet points, I encourage you to step back and ask yourself "Why is it that way?" Don't settle for "because". Investigate, and don't stop until you know the reason. There is a reasonable explanation for each of the points you raise. But you won't be convinced until you do your own investigation and realize, in each case, "Oooooh! I see." And when you do reach that stage, you'll be a better Perl programmer for your effort.

If, at any point, you reach a full understanding of the issues surrounding each of your bullet points, and still feel that there's a better solution, put it in a proof-of-concept module, upload to CPAN, and see if people like it. Fully researching a topic, and producing a better solution... that's progress. Knee-jerk reactions to constructs that you haven't taken the time to fully investigate will not produce a better Perl. Nor will they make you a better programmer.

(Update) Learning why a language works the way it does will make you a better programmer, whether it's Perl, Lisp... even PHP.

.... Knee-jerk reactions to constructs that you haven't taken the time to fully investigate will not produce a better Perl. Nor will they make you a better programmer.

Having thoughts and bravely sharing them, is a good first step on the journey to enlightenment :)

I'll accept that. :)

This was a meditation, after all. My hope is that these bullet points are really just seen as a list of things to investigate further, to earn better enlightenment.




Dave

>> All of these bullet points enumerated in the top post of this thread are just annoyances or surprises to someone who comes to Perl from another language.

And I think that my bullet points are mostly indifferent to other languages. I'd write same bullet points if I weren't familiar with other languages.
Also one bullet: I wanted to write that I little dislike assignment operator "=" (C lang family), maybe because firstly I was learning "Pascal" (":="), but stronger motive is that assignment has direction, so that operator hasn't vertical symmetry axis or symmetry point. I'd like to use symmetric operators for commutative operations, such as +, -, *, but for non-symmetric operations - use non-symmetric: =~ , <<,... But his rule difficult to realize, because then operators would consist of too much signs. Hm.. maybe I'd rather use "&~" operator for smartmatch, but it is a little more difficult to write.

Anyway, the dark corners of Perl are not that ones!

I don't understand the second question. Do you mean my should be prepended to any variable name? Or only some of them? Which ones?

Maybe to prepend for every users new variable, and not prepend to default special variables ($_,$/,...). But if user wants to change it he could prepend by himself "our" or smth. Bad idea?

Yeah, bad idea.

Consider the two proposed automatic mys in the following code. It avoids an obvious compile time fault ($line), while causing a silent run time fault ($indux).

use strict;
use warnings;

my $index = 0;
while ($line = <>)
{
  frobnicate($indux++, $line);
}
[download]

Appended Re: LanX's comment

If only applying the my to assignments initializations, then consider this code with the same issues:

use strict;
use warnings;

my $faultsInARow = 0;
while ($line = <>)
{
  if (frobnicate($line))
  {
    $faultsInaRow = 0;  #Initializing a new variable by mistake.
  }else{
    $faultsInARow ++;
  }
}
[download]

Bad idea!

Who does the work on an editor (which editor(s)?) to:

1. "prepend" the "my" to vars
2. to make the programmer's intended choice among "my," "our" and "local"
   ... and
3. to distinguish between a new global $var and one in a sub in which a $var gets localized?

Most of us find it possible to write code without too much agita over Perl's (sometimes idiosyncratic) tools that help us achieve our intent in/with the finished script.



This is a no-whining zone (well, we'd like it to be a no-whining zone!

my and our declare new variables in Perl much like int, char, float and others declare new variables in C++ (and C). Though Perl's my and our are, technically, scope specifiers while C++'s int, char, float and others are type specifiers. Still, the concept is the same: Declare new variables before you use them.

Special variables neither need to nor should be declared in your Perl code.

That is what Python2+ does (autodeclaring at first assignment), with side effects on closures, which forced Guido to introduce 'nonlocal' in Python3.

Apart from this does Python not use blockscoping¹ (IIRC) like Perl does, but only function scoping, so far less edge cases to be considered.

I wouldn't say an automine pragma would be necessarily bad, but it would cause considerable headaches to avoid incompatibilities and extra thoughts to catch typos blowing up at runtime.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

¹) i.e. block in the sense of e.g. the body of a loop

The keyword my was, at some time or another, merely someone’s syntactic choice ... to go along with our, perhaps.   The key notion here is that identifiers are declared, to gaurd against typos that your eye will automatically read-over ... like the typo in this very sentence.   If “all identifiers are declared,” the compiler can, at compile time, point-out that the variable-name guard is mis-spelled and that you really didn’t intend to have two variables.

Nevertheless, the design (the philosophy?) of the Perl language is that you are given that sort of choice.   If you choose to use these compiler-features (and you should ...) then those strictures will be enforced.   But if you do not, they won’t.   Odd as it may seem to you, even “wrong” as it may seem, this is a design choice.

Many languages do carry “compile-time checking” to a much greater extreme than Perl does.   They implement strong-typing, and rely much less on at-runtime decision making to carry out The Author’s Intent.   Each approach, however, is neither right nor wrong.

Perl will never “fundamentally change,” no matter how “–er” any particular fee-chur is thought to be, because that would break the most important thing:   compatibility with the tens of millions of lines of mission-critical application code that has been written using it over the past decade(s).   The same is true of every tool that has escaped the ivory tower (or, as with Perl, never was inside of one).

The keyword my was, at some time or another, merely someone’s syntactic choice ... to go along with our, perhaps.

my came way before our...so it was 'perhaps' the other way 'round.

I was shocked to read that, till ...

  DB<24> $h{length}=3
 => 3

  DB<25> \%h
 => { length => 3 }
[download]

... I realized the behaviour is sane (autoquoting of barewords) and that you want it reversed to DWIM magic which is easily avoided with little explicit syntax.

just use parens if you really want to avoid an explicit $_

  DB<33> $_="abc"
 => "abc"

  DB<34> $h{length()}=42
 => 42

  DB<35> \%h
 => { 3 => 42, length => 3 }

  DB<36> $_="abcd"
 => "abcd"

  DB<37> $h{(length)}=666
 => 666

  DB<38> \%h
 => { 3 => 42, 4 => 666, length => 3 }
[download]

In this contrived case ( length as a hashkey? ) I'd personally reject anything other than

  DB<39> $h{length $_}= 'best'
 => "best"

  DB<40> \%h
 => { 3 => 42, 4 => "best", length => 3 }
[download]

in code review.

Question Are you possibly unconciously trolling???

Opinion I doubt that ... but keep on trying to entertain us.

I don't know if it is trolling? (Yesterday I read some articles about popularity of Perl and tried to remember which things in Perl took away some of my time and mood; And I think that they could be annoying for other beginners.)

Why did I used $hash{length}? It's because I used $array[length] many times. And usually I suppose (cargo-cult?) that similar construct should behave similar. And I have used $hash{1+1} before, and haven't gained "('1+1' => smth)". So I dislike that bareword exception that you mean.


$_="abc";
$h{1+3}=41;
$h{a+3}=42;
$h{- length}=43;
$h[1+3]=41;
$h[a+3]=42;
$h[- length]=43;
$h[length]=44;
$,='|';
print %h,"\n",@h
__END__
-length|43|4|41|3|42|
|||43|44|41
[download]

I can't imagine many cases at all where you might want to use length $_ as an index or key, but almost every case where you would want to be able to type a key without having quotes all over the place.

The simplest way to do what you want is with a leading unary + to make it not be a bareword.

use strict;
use warnings;
use Data::Dumper;
my %foo;
$foo{+length} = 42;
$foo{length} = 'interminable';
print Dumper \%foo;
[download]

Gives:

Use of uninitialized value $_ in hash element at test.pl line 5.
$VAR1 = {
          '' => 42,
          'length' => 'interminable'
        };
[download]

1. I don't think I ever wanted such a thing
2. So you'd rather have $array[i][j-1]? That would mean that whenever you need to copy the expression between inside and outside the square brackets, you'd have to add/remove $. No thanks!
3. Backwards compatibility for use strict and you DO WANT those my()s.
4. Sorry? I don't understand what do you want with the reverse. You can write $_ = shift; in main, but as @_ doesn't mean anything there, you get the next from @ARGV ... that is the script's parameters. Makes perfect sense.
5. I'm inclined to agree here. I'm not so fond of dots though.
6. You can: $i > 5 or do {print "No"; last}. It's better to use if(){} or unless(){}
7. Within curlies, if it looks like a word, it's automatically quoted. It simplifies the code. I don't see how the magic of ++ hurts anything. What did you expect to get from $x = "a"; $x++?
8. The parser is insanely complicated already, besides what would print 1 + foo(1+1)*2; mean then? Should the foo get 2 and then get its result multiplied by two or should the parser wait for the end of block or semicolon and pass 4 to foo? The rule that guides the first distinction is fairly simple ... If a subroutine name is followed by an opening brace, then its parameters end at the matching closing brace. If not THEN the parameters end at the semicolon or end of block. Keep in mind that print is just a function and it does return a value, even if that value is most often ignored. The filehandle stuff ... well, it's a bit tricky, but the rule above still holds. Don't expect special handling for print and you'll be fine.

Thank you all for interesting answers and discussion!

>> So why do you complain that the following is onerous?
I wrote that it seems to be basic (basic math function), so that means that it shouldn't introduce by POSIX. Basic math functions I keep: sqrt, abs, ceil/floor, round, (odd/even), sin/cos/tan/ctg, exp, some others. So I dislike Python no less.

>> 2) chomp(@foo); is simpler than @foo = map chomp, @foo;.
I meant "chomp(@foo)" - would do as it did. Only what it return differs. But then we couldn't get last character - that's also bad.

>> Making an exception for length would be bad (very error prone).
Why error-prone? ...And if you use text redactor, you always see "length" same color as other functions and non-barewords.

>> So you'd rather have $array[i][j-1]?
Yes, it would increase readability (if there are many indices, and nested). But sure, I can't suggest anything better.

>> You can: $i > 5 or do {print "No"; last}.
Thanks, I haven't used "... or do ...", but I can't understand why language has two different constructs ("{...}" with and without "do"), and I remembered strange thing about such blocks - that you can't use last (and friends) to escape unless you use {{double block}} (one more exception rule).

>> What did you expect to get from $x = "a"; $x++?
"b". I expect to get "a", if statement would be ($x++)--. I think that if Perl differentiates numerical and string operations writing them by punctuations and letters (e.g. firstly I started to use binary: cmp, le, eq, ne,... and <, =, >=, +, -,...), then it could use something different for string and numeral increment, for example: ++ for numeral, and "up" for string, -- for numeral, "dn"/"dw"/"down" for string.

>> The parser is insanely complicated already, besides what would print 1 + foo(1+1)*2; mean then?
It could be a rule of syntacsis, that function take ALL things till the closing paren (w/o opening paren) or thing that is less tight (or/and). So answer for example would be "print 1 + foo 4", and if we would like to have foo eaten only "(1+1)", then we should write "print 1 + (foo 1+1) * 2". With this rule we could everytime omit the outermost pair of parens.

I agree that most of the stuff that's in POSIX should be either in the core or in some saner named modules. This module makes no sense whatsoever.

The $array[i][j+1] looks good only as long as you use single letter indexes. What would $array[length] mean? $array[$length] or $array[length($_)]?

Because one is block and the other is expression. Just use if(){}!

Well, I would agree that if ++ is magical, -- should be as well. I do not see the need for a separate operator/function though.

That would be way more confusing. If you write foo(...) anywhere within an expression, everyone except those coming from functional languages with support for currying will expect that function to receive as parameter(s) the stuff in braces and only that stuff in braces.

Jenda
Enoch was right!
Enjoy the last years of Rome.

As many have already stated: your "expectation" does not match. That is no reason to state that either your expectation or the language (perl, C, java, PHP, Python, assembler, Cobol, Fortran, Basic, Forth, ...) is wrong.

Your expectation has grown out of your experience with other languages. Those languages have made design decisions that differ from most of the design decisions made in any of the other languages. If all used the same reasoning, there would only be one language :)

What currently sound non-sensical or illogical to you at first glance, might be superduperlogical when you understand *why* it works like it does and what power you can get in using it the way it does.

The beauty/ugliness is withing the eyes of the beholder. There are as many styles and layouts as there are people willing to dispute whatever other style. Perl5 is known to allow a lot of styles and structures. The main reason is that perl was designed by a linguist, and not a compiler-designer or somesuch. The fact the your can write action() if expression; to mean exactly the same as expression and action (); is a fact that both attract programmers to the language (as it is easy to fit your coding to the way *your* brain works) as it chases people away (too many different possibilities to do the same thing). Obviously, I am in the first camp.

One gets used to the language most frequently used (in a period). I'm doing perl, java, and C. Do not count my curses when the C compiler failed compiling my code where I typed state $i = 1; instead of static int i = 1; (same for my etc).

Likefile I curse at java IDE's for deleting lines when I hit Ctrl-E expecting to scroll. An IDE is not (sadly) my fav editor. Speaking of which: flamewars have proven in the past that there is no editor that suits the needs of every single person that uses it.

So, there are for sure "things" in the perl language that may be counter-intuitive for you until you know why the specific feature acts like it does. For people coming from perl, it is exactly the same the other way round.

I value your first post, as it lists a basic set of expectations. Not that I agree to those expectations, but we all can learn from that list what *some* people might expect in any language. For some of those grunts, there are (very) easy solutions or workarounds, for others, you'll just have to accept that language X does not have the same syntax as language Y.

If you seriously take time to get over your initial griefs, I am sure you will see the beauty and grace of perl and learn to love the ease of use and the widely available off-the-shelf ready-for-use CPAN solutions.

There is zero doubt in my mind that CPAN is really “most, if not all,” of what the fuss is about, when it comes to Perl.   Every language has its contributed-library and its system for deploying it, but I believe that Perl’s CPAN is a best-of-breed resource.   It is comprehensive, extensive, and very thoroughly self-testing.   It is also “battle-proven.”

The language itself is also well-implemented and remarkably flexible.   Consider, for example, that Moose is written in Perl-5, thus is compatible with Perl-5 and in fact allows you to switch back-and-forth between the two idioms within the compass of a single source-file, if you choose.   (And, on top of all that, it’s efficient.)   Nor is it the only version of itself ... there’s also Moo and many, many others.   I’m not coming-up offhand with any other language that’s actually capable of that.   Let alone in a way that you can, and do, put into production deployments.   Perl is no one’s toy.   Wanna haul serious freight for money?   Hitch up the train and let’s go.

So, while I freely grant (from personal experience ...) that Perl will initially trigger a “WTF™ ...?!” reaction, perhaps especially among those with fewer notches yet carved into their pistol-grips, it is a language well worth getting to know, and getting to know well.   Whether or not you find it attractive.   (At first.   It grows on you.)   The saying that it is “The Swiss Army® Knife of pragmatic computer-programming” is not an idle quip.

Some options always present themselves.

package lvals {
  sub import {
    shift;
    no strict 'refs';
    *{caller.q(::).$_} = do{ my $x; sub () :lvalue {$x} } for @_;
  }
}
1;
[download]

use lvals qw(i j matrix sum);

matrix = [([1..10]) x 10];

for(i = 0; i < 10; i++) {
  for(j = 0; j < 10; j++) {
    sum += matrix->[i][j];
  }
}
print "Matrix sum is ", sum;
[download]

/me quickly hides under the rock.

I missed this. I'm so glad that it was a slow night/morning when astroboy posted.

++ and props!

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

+0.9 upvote

full points only if you change the package block into a backwards compatible way! ;-)

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: lvalue subs are unfortunately a little bit slow compared to real scalar variables...

PS: lvalue subs are unfortunately a little bit slow compared to real scalar variables...

Like in real life: You have to spend some $$ to get faster... :-)

Regards
McA

P.S.: After working with Python for some time I think that sigils are not too bad. They give hints for the reader. But sure, it doesn't look so clean.

nice!

Whay all the code must have so much my my my my...?

my restricts the scope of a variable. The scope of a variable is where it can be seen. Reducing a variable's scope to where the variable is needed is a fundamental aspect of good programming. It makes the code more readable and less error-prone, and results in a slew of derived benefits.

If you don't declare a variable using my, a global variable will be created instead. This is to be avoided. Using use strict; tells Perl you want to be prevented from implicitly creating global variables, which is why you should always use use strict; (and use warnings;) in your programs.

Shrug...   “When in Rome, do as the Romans do.”   You won’t find a single programming-language made by humans (as opposed to the space-aliens who haunt the hallowed halls of Academia ...) which does not contain a double-handful of “idiosyncracies” just like these.   They are only strange and objectionable when they differ from the just-as-idiosyncratic idiosyncracies of the language(s) that you are now used to.

Perl is one of the more-difficult tools to get to know, partly because it is quite lassiez faire:   “TMTOWTDI™ = There’s More Than One Way To Do It,™” and Perl does not tell you which road to take.   Many people, especially those fresh from academic institutions, are more accustomed to strongly-typed languages which have a strong and explicit sense of “at compile-time” error-checking.   Perl is not-at-all like that.   If you do not wish to use strict; use warnings; then Perl will not demand that you do so.   (Whereas other language systems might barf that “you did it Wrong” and, having not run the program at all, refuse to do anything.)   It will do its best to figure out what you meant to do, so to speak, and it will do something.   This is by-design, but it is initially unsettling to many.   Of all the languages I use regularly, Perl just might be the one that it took me the longest to come to know.   However, today, it remains one of the small handful that I use most often.

1) Perl does not have integer division operator. It must call "use/no integer" to change type. Python has: / - normal division, // - integer division. Sugar.

2) It is not problem for me to read dollars in single variables. But it is annoying to read them in some-dimensional arrays (it's noisy), e.g. $array[$i][$j] > $array[$i][$j-1]

It is strongly recommended to "use strict" and make variables "my", then why it is not default? Whay all the code must have so much my my my my...?

Doesn't work - "$_ = reverse";

If in subroutine I can write "$_ = shift", why can't I write so in main (I need to write "$_ = shift @_").

5) It was strange that "cho(m)p" returns last symbol, not a string w/o last symbol. Ruby's cho(m)p I like more, because I can proceed on string: gets.cho(m)p.split.do_smth...

Can't use blocks using "and/or": "$i > 5 or {print "No"; last}"

(overcome - "$i > 5 or (print "No"), last"; comma is tighter than "or" but it is counter-intuitive for me)

It was suprise for me that when I used "$hash{length}" it interpreted (length $_) as "length"; Surprise was that ++ has magic (I need to know exceptions) and -- has not; Surprise that "use bigint" doesn't DWIM in some cases.

perl -CO -Mutf8 -wE 'my ( $x, $y ) = qw( a а ); say ++$x; say ++$y'

Difficult exception is that "print (1+1)*2" != "print 2*(1+1)" == "print STDOUT (1+1)*2". I think "print(..." should better wait until the end of block or ";".

I think some of their critisim is not justified. Still, it appears to me that the OP would be happier with something like Forth

Doesn't work - "$_ = reverse";

Come to think of it... I became puzzled why it doesn't work.

$ perl -E '$_ = "skrow"; $_ = reverse; say'
works
[download]

Perhaps the OP meant print reverse or something. So, not true.

Probably something to do with reverse operating on scalars or lists and print operating on a list. Using scalar forces scalar context so that reverse operates on $_; not sure what it defaults to operating on in list context :-s

$ perl -Mstrict -Mwarnings -le '
$_ = q{skrow};
print reverse;'

$
[download]

$ perl -Mstrict -Mwarnings -le '
$_ = q{skrow};
print scalar reverse;'
works
$
[download]

I hope this is of interest.

Cheers,

JohnGG

I agree that I dislike excessive keystrokes. I dislike to write $num = ($x - $x % $y) / $y. I think that not having sqrt is bad, but not having integer division is awful. How much newcomers didn't find integer division and go to search other language to learn? Idk...

If someone use my my my near the all variables, why shouldn't it be default? I don't know how often others use my. If >80% variables precede by "my" it could be stated as default, if not then not.

>> $_ = scalar reverse works. Additional word.
In book from where I started to learn Perl (it is translated to my language and shortened) there were some tables: [special symbols], [logical operators], [other operators], [precedence operators](my favourite), [regex metacharacters], [regex modifiers], [special variables],... but there were no table where are written: function + what for it asks (scalar or list). Maybe it would be useful table for newcomers...

"$i > 5 or (print "No"), last"
This works as I wanted. For example:

while(<>){
/^i'm tired$/i and (print "Good by!"), last;
...
}
[download]

rsFalse:

Rather than $num = ($x - $x % $y) / $y, why not use $num = int $x / $y? I agree that having to use the former would be a bit troublesome. When you mentioned integer division in the OP, I couldn't figure out exactly what was so troublesome about using int. Seeing this, I'm thinking that maybe you're just not aware of it.

Update: I forgot to mention, perl has the sqrt function.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

think that not having sqrt is bad, but not having integer division is awful. How much newcomers didn't find integer division and go to search other language to learn? Idk...

That's correct. Perl is not the right tool for all jobs. It excels in some things, notably processing text, and this is what I use it for. I wouldn't use Perl for some numerical work (actually, I probably would but I already know Perl; I wouldn't learn it for that).

If someone use my my my near the all variables, why shouldn't it be default? I don't know how often others use my. If >80% variables precede by "my" it could be stated as default, if not then not.

Party due to historical reasons; the early versions of Perl didn't have lexical variables, so they couldn't be the default (and a LOT of thing in Perl are the way they are due to history). Another (perhaps bigger) part is that many (most?) Perl programmers find it a genuinly useful feature.

I'm conviced that it would be very good if strictures and warnings were always enabled by default, and it's really unfortunate that that can't happen.

In book from where I started to learn Perl (it is translated to my language and shortened) there were some tables: special symbols, logical operators, other operators, precedence operators(my favourite), regex metacharacters, regex modifiers, special variables,... but there were no table where are written: function + what for it asks (scalar or list). Maybe it would be useful table for newcomers...

I don't see how perlop, perlre, or indeed, perlfunc can be reasonably shortened, compared to the originals.

Perl is a big and complex language. It perhaps would be better in some respects if it were smaller and easier to learn... It is what it is, though.

I have some great news for you - perl is open source! This means that you are free to fork it and produce your own version tailored precisely to how you wish things were done. Of course, it won't be compatible with original perl, but that's clearly not a concern for you. Good luck with your endeavours and be sure to post back when RSFPerl is ready for download.

1) Perl does not have integer division operator. It must call "use/no integer" to change type. Python has: / - normal division, // - integer division. Sugar. To use things such as "ceil/floor", I need to "use POSIX"... Aren't they basic?

2) It is not problem for me to read dollars in single variables. But it is annoying to read them in some-dimensional arrays (it's noisy), e.g. $array$i$j > $array$i$j-1.

3) It is strongly recommended to "use strict" and make variables "my", then why it is not default? Whay all the code must have so much my my my my...?

Who cares about integer division?

I do, quite often. First thing that sprints to mint is the fact that my screen doesn't have fractional pixes. Fractional arguments are illegal (as in they cause a croak or die) on many API's.


Enjoy, Have FUN! H.Merijn

OK, right, I might have overstated the case, but we have int, don't we? Not to mention use interger;