Hacker News Reader

Thanks for the link.

That's one thing I love about Hacker News; all of the links y'all leave that lead to further study and growth.

Python being readable is FUD. I've seen tons of horrible Python. Of course, I've also seen tons of horrible Perl (and PHP, and even Lisp).

Basically, in the hands of incompetent programmers, everything is unreadable. If you are disciplined, you can write easily-readable Perl. I (and my coworkers) do it every day.

Oh, one other thing... the linked article is from 2000. In the last 8 years, the Perl community has figured out how to program... so most of his points aren't relevant anymore. Nobody writes 2000-style Perl anymore.

one can write readable anything, but some languages encourage it more, both in the language features and syntax, and also in the community, tutorials, etc

Yes, Perl encourages readability in the language by one of its language features, the helpful prefixes in front of variable names.

This is a joke, right? You can't possibly be serious.

No, I was serious.

When I look at a variable in Python, say, p, to take an example from the code shown in the Python documentation, there is no way to tell what p is. Is it an array? A dictionary? A tuple? Something else? With Perl I get more information just by looking at the variable. That makes it more readable.

Python, on the other hand, is still very nice. Maybe one of these days it will get me, especially if the libraries grow to match the breadth of CPAN.

Incidentally, I often see people complaining about non-idomatic python tutorials here.

What I see from this is that people will try to TMTOWTDI regardless of whether or not that's the language's philosophy. At least Perl prepares you to expect people writing code that doesn't look like yours.

(And I'm used to people's weird styles. I have one friend who makes every line of code its own subroutine, and another that gives every method a super_descriptive_but_way_way_too_long_name. You get used to it, and emulate it when appropriate. It's better to decide on a style with your friends/coworkers instead of being told what to do by some guy that works at Google you've never met.)

Perl is more readable to someone who knows Perl, because it gives you indications what type each variable is:

$ for scalars (single values without dimension)

@ for arrays

% for hashes (like python's dictionaries)

With python, you have to guess.

Of course, many people who are intimidated by Perl have made the same statement about readability, and it is often repeated unthinkingly. That doesn't mean it's true.

On the other hand, Perl does make it easier to write unreadable code. Just like any powerful tool -- cars, telephones -- it can be abused.

All that being said, I think Python is a great choice too; I just disagreed on the readability point.

because it gives you indications what type each variable is:

Not really. Guess what type $foo is in each case:

    my $foo = [];
    my $foo = {};
    my $foo = "Hello, world.";
    my $foo = \"Hello, world.";

while completely ignoring the right hand side, i can tell they are all scalars.

Looking at the right hand side, I can tell the type of the value in that scalar type! ... the value type is a different thing than the variable type

We can really debate and argue about the value of typeful variables ... the value seem to be that it allow a combination of syntactic sugar and availability of the reference type!

So basically, if you want a reference type, you need syntax to dereference the reference.

And if you have that, you will eventually need syntax sugar for when you dont want to use the dereferencing syntax.

This is probably why in Perl things are the way they are!

I am not sure thought if the reference type is at all needed, it some occasions I see it clarify cases when values are passed by reference vs passed by value, because a reference in Perl is a real value, not something that is implied! ... but this i would say is largly subjective

I don't understand most of your post (too many ...s that aren't clear), but you should probably stay away from the word "type" when you are talking about Perl variables. "Scalar" doesn't really mean anything. If anything, it describes the cardinality of the contained value, but certainly not the "type".

Even values stored in variables have very flexible "types" that I wouldn't really call a "type".

If you store "42 is a number" in a scalar, you still don't have a type. Maybe it's a string, maybe it's an integer, maybe it's a boolean. Types only show up when you apply an operator. If you say "42 is a number" - 42, then the result is 0 because "-" coerces the string into an integer (actually a SvPv to an SvPvIv, and then looks at the integer part of the data structure). This is different from other languages that choose the operator based on the type of the value (look at how SBCL chooses the right + operator to used based on the types of the contained values. the exact opposite of Perl).

As an aside, this coercion isn't an implementation detail; Perl exposes it all to you. If you "use overload", you can have "boolify" subroutine called when someone does "!$your_object", a stringify subroutine that's called when someone does "$your_object =~ /.../" or "qq{$your_object}", a "numify" subroutine that's called when someone does "$your_object - 42", etc.

Anyway, not sure what my point is... but don't use the word "type" to talk about values or variables in Perl. It just doesn't make sense. Perl is totally different from other languages here, and the word "type" has too much incompatible baggage associated with it.

okay, in summary, I wanted to say.

In Perl $ means scalar, @ means array and % means hash

Those are variable types, you learn them by looking at the variable syntax or name

The value pointed to by those TYPED variables can be more complex, you can have integers, floats, strings, references, reference to a string, reference to array, reference to hash, array of strings, array of references etc .....

but the variable type won't tell you about these complex structures, it will only tell you that the value is $ scalar or @ array or % hash ... and in that there is no confusion, all the variables you mentioned above are typed scalar and can only point to values of type scalar

I understand your problem, since a scalar can be a reference to an array

you want to think that $ref = [] points to an array but it doesn't it points to scalar which happens to be a reference to an array!

you can for example do this

my $ref = [];

$ref->[0]= 0;

say $ref->[0];

$ref = {};

$ref ->{0} = 1;

say $ref->{0};

but you can't do this

my $ref = [];

$ref->[0]= 0;

say $ref->[0];

## $ref = {};

$ref ->{0} = 1;

say $ref->{0};

because in $ref ->{0} = 1 the assignment is to value referenced to by te scalar, and this value type is not a hash and can't have a hash member {0}

The whole references thing is the biggest pain in the ass in Perl syntax. List flattening, and the fact that arrays and hashes can only store scalars (or a reference to something else), etc. just expands into every nook and cranny of the language.

I still have a hard time with this aspect of the language after 10 years of Perl coding (with a three year break where I mostly worked with Python). And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point. Perl 6 fixes many of the painful bits but not all.

But, nonetheless, I'm more productive in Perl than any other language. Partly because of the massive library of excellent pre-existing code, and partly because my problem domain almost always involves text parsing/processing and dealing with system-level data which are things for which Perl was designed.

And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point.

Not really:

  my $ref  = [qw/foo bar baz/];
  my $ref2 = [map { uc } @$ref]; # [qw/FOO BAR BAZ/]

References, if anything, are just slightly ugly. I could live without non-reference values, however. They're basically useless, but sometimes they make the program more concise.

I think everyone realizes this mistake, however, and Perl6 only has types that behave like references:

  my @foo = split '/', "foo/bar/baz";
  function(@foo, 'hello');

  sub function(@foo, $string){ ... }

My point was that it is an additional bit of friction that isn't present in Ruby or Python (though they also have their own bits of friction). Even though I've written a lot of code in my life, I've never been a full-time software developer, and so it's one of the tricky bits that drops out of my head during the breaks in between writing code. I'm interacting with code written by someone very comfortable with these idioms, and so they show up all over the place, and I never quite get them right the first time. I just think it's an area that makes Perl trickier than it ought to be...it's not a deal breaker (PHP's lack of first class functions, for example, now that's a deal breaker). I'm basically a raving Perl fan, but arrays only holding scalars is a nuisance.

And, as I mentioned, Perl 6 goes a long way to correcting pretty much everything I don't like about Perl 5.

PHP's lack of first class functions

Thanks for that lil' tidbit.

It's the

    @{$h{$k}}

syntax that's fugly. +1 for Python.