[gdog]

Please don't make assumptions about my Perl knowledge as I don't make any assumptions about your technical knowledge. I'm actually a Perl Programmer full time.

Yes, Perl does have pointers in it. The term 'References' (in Perl) is marketing cover up you fell victim to. Run this: my $x = [1, 2, 3]; print $x; It prints ARRAY(0x206a998) on my machine. There's a address and a type, that's a pointer. Please read the Steve Yeggie I posted above (he explains it quite well) and then reply back (if you are so inclined).

>It does? Do you mean references? You'll need to use reference syntax when using nested data structures, but this is the same syntax that you'll find in Python and Ruby - you could think of those languages as using references by default instead of having array or list types.

So I have include 2 modules do something incredibly basic and fundamential to all programming languages. What a joke. C has been doing this SANE behavor since the 80s (maybe seventies). Along those lines (sorry, I'm being sarcastic to get my point across) why don't we have all scalars get random wrong values (after you assign something to them)? Then you can include a module Variables::UseRealValues so it behaves correctly. Then Perl fanatics can tell me how other languages are less flexible and Perl via TIMTOWTDI is better.

> This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.

Fair enough, I meant type error. I know what scalar is.

> Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python). This throws a lot of people off, when they expect it to work like Python or Ruby and it doesn't. "abc" and 1 are actually the same type - scalars. A scalar can be a number or a string behind the scenes, and they're automatically converted, so you can just read data from a file and not have to worry about that. You want to use the dot operator, `print "abc" . 1;`, which prints "abc1" (which is what I think you want). In those languages, it throws a type error, not a syntax error, which is an important distinction. Intergalactic law states that you're not allowed to complain about Perl if you don't know this.

Yes other languages have warts. Perl just has more of them.

>Perl has warts just like any other language. Its warts are just more infamous (because Perl is used so much, a lot of people are having to maintain old codebases) and more visible (Perl has a culture of using the CPAN to fix things with the language (MooseX, Modern::Perl) whereas other languages' users tend to just put up with it).

But people don't just learn from books. All of us google how to do a particular task when we doing it (especially under time constraints). With Perl's unwieldy syntax you're likely to copy something wrong (I don't just even mean cutting and pasting, but concepts). Someone will probably have to read this code later. So 'on paper' it doesn't make you're language worse (as you question below) but in practice (and that's what really matters) Perl's lots of wrong ways to do it really shoots you in the shoot.

> If you learn Perl from a book, the amount of sub-par Perl code in the wild isn't going to affect you. Or, to put it another way: how can someone else make my language a worse one merely by writing in it?

I find it slightly annoying all these 'why I use Perl' links on hacker news. Advocacy is lame. With Python or Ruby you'll see more links on a new library or a tutorial (like math library on the front page). Rarely do you see a 'why I use Ruby' or 'why I use Ruby' link.

One final thing, for all my Perl critism I find the community intelligent and very helpful. I just think the language is poor and they should move on alreay to Ruby or Python. It's a shame they waste on their talents on Perl.

[chromatic]

In Ruby can write `puts Object.new.inspect` to get something like `#<Object:0x7f88ded4cc68>`. Does that mean Ruby has pointers?

If you can't do math on it to access other parts of memory, it's not a pointer in the C sense.

[gdog]

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

[chromatic]

I'd say it's more a like a pointer than not.

Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

What you see in Perl (and Ruby) is a unique identifier that happens to be a memory address. It could be anything else, but the memory address is an identifier that's essentially free to generate. That's it. It's otherwise irrelevant. You have to write code in a language which has pointers to do anything with that information, and even then you have to cast it to a real pointer to do so.

We could discuss Perl 5's dereferencing syntax (it's ugly, no argument there) but that's a syntax issue and not an implementation concern.

[gdog]

I'm familiar with C and understand why pointers are there. I understand what you are saying and you make a fair point. I'll take back my statement Perl has pointers. Claiming Perl has pointers is very murky (although it has some truth to it). The heart of what bothers me is you have to deference addresses (similar to what happens with pointers in C) in Perl. This shouldn't exist in a scripting language syntax. It lots of unnecessary syntax, compile errors, and mental hoops you have to go through when coding. Ruby and Python don't have this serious (I think so at least) wart.

> Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

[chromatic]

The heart of what bothers me is you have to deference addresses...

I don't understand why you keep saying that. They're not addresses.

From the language side of things, they're first class scalar entities just like strings and numbers. From Perl 5 they have nothing to do with memory addresses. (You might as well suggest that a nested data structure in any language without pointers is "dereferencing addresses", or that accessing object attributes is "dereferencing addresses".)

You can't write in Perl something like:

    my $reference = 'ARRAY(0x1234abcd)';

... and expect to access the array at that point in memory even if you stringified an array reference and saw that its stringification included that hex address. References are not pointers. They don't dereference addresses.

From the internals side, they're SVs, just like all other scalars in Perl 5. An SV is a C structure. Yes, the internals use pointers, but so does any other virtual machine implementation.

(Okay, you can write code like I said above, but to make that work correctly, you have to write C to do it, because C allows direct access to memory by address.)

[gdog]

I'm sorry. I'm actually a little dyslexic and if a wrong word slips by the spell check I can get myself in trouble. s/deference/dereference/.

Consider: my $x = [1,2,3]; print "@$x\n";

In the second line I consider "$" dereferencing the "address" that points to an array. I don't know anything about the internals of Perl virtual machine and what that "address" really means. But to the common programmer it seems like you have to do the same work you would have do in C dereferencing pointers. Python and Ruby have no such operator, right? This unnecessary work is what I'm complaining about (and all the associated extra syntax).

[gdog]

I don't understand why this is getting down voted.

[kbenson]

Because some of your assertions are factually incorrect. That's a valid reason to downvote.