Your post gets a number of things wrong about Perl.
> For crying out loud Perl has pointers in it.
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.
> Perl doesn't do basic parameter checking in functions.
This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.
> Perl doesn't come with a decent repl.
Yeah, this is annoying. Get Devel::REPL and use that.
> 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.
> wantarray is one of most horrible things I've seen a programming language
Having list flattening means you can dump all kinds of data into a function and not have to worry about where it came from. Recently I wrote the line of code `highlight qr/regex/, @colours, @more_colours`, where I just dumped values from arrays into the function and didn't have to worry about destructuring them. If I wanted to pass the arrays, I'd put a backslash before them. It's sort of the opposite of Ruby's unary * operator.
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).
I disagree that the average code is what counts. When I helped out on a Python cause, the lecturer barely knew Python, and taught it as though it were C (the students learned while loops first, then for loops, and never actually learned about generators. Yeah, I know). The code they wrote was definitely below-average. But not once did they turn to the Internet to see what proper Python code was like - they just followed the course, and did what it told them. 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 do agree that Perl is a bad choice for your first language: the choices it gives you and the amount it leaves up to you could get confusing when you're trying to learn it by yourself. Perl is a language for when you're a better programmer, and you've learnt to code at a higher level.
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.
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).
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.
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.
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.)
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).
> For crying out loud Perl has pointers in it.
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.
> Perl doesn't do basic parameter checking in functions.
This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.
> Perl doesn't come with a decent repl.
Yeah, this is annoying. Get Devel::REPL and use that.
> 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.
> wantarray is one of most horrible things I've seen a programming language
Having list flattening means you can dump all kinds of data into a function and not have to worry about where it came from. Recently I wrote the line of code `highlight qr/regex/, @colours, @more_colours`, where I just dumped values from arrays into the function and didn't have to worry about destructuring them. If I wanted to pass the arrays, I'd put a backslash before them. It's sort of the opposite of Ruby's unary * operator.
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).
I disagree that the average code is what counts. When I helped out on a Python cause, the lecturer barely knew Python, and taught it as though it were C (the students learned while loops first, then for loops, and never actually learned about generators. Yeah, I know). The code they wrote was definitely below-average. But not once did they turn to the Internet to see what proper Python code was like - they just followed the course, and did what it told them. 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 do agree that Perl is a bad choice for your first language: the choices it gives you and the amount it leaves up to you could get confusing when you're trying to learn it by yourself. Perl is a language for when you're a better programmer, and you've learnt to code at a higher level.