Comment by gdog | Hacker News Reader

Comment by gdog | Hacker News Reader

I'm writing to beginner programmers. Please, please don't use Perl.

Use Ruby and/or Python. Other competing scripting might be good (like lua) but I haven't used them. I do know however Ruby and Python are better.

see https://sites.google.com/site/steveyegge2/ancient-languages-...

90% still holds true. This guy knows more than 99% of the Perl advocates on this thread (he's also smarter than me). Do another search on other famous programmers (like Rob Pike) and almost always you'll find negative comments about Perl. There a reason companies like google use Python and universities (like MIT) teach in Python.

For crying out loud Perl has pointers in it. Perl doesn't do basic parameter checking in functions. Perl doesn't come with a decent repl. The Perl repl doesn't work with readlines. Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python). Do some basic google searching. wantarray is one of most horrible things I've seen a programming language thats unique to Perl. You how know generally side effects are bad in functions? Well, I don't want to get into it... but just google it.

Perl has a weird cult culture to it. There are a few smart people who are really into it but it isn't because of the languages merits. This is well described by one of perl most famous developers: http://www.perl.com/pub/2000/12/advocacy.html No one with a OPEN mind who isn't lazy wouldn't move onto Python or Ruby.

Remember too at the end of the day it is how good or bad code theoretically is. Is what you see out in the wild. What you work with. The chances are you won't be looking at chromatic's code. Perl code is about the ugliest, most unreadable code you'll find on average. I recently saw something Brain D Foy (a Perl expert) acknowledging this. The average code is what counts.

Anyhow those are my 2 cents. I have to go to sleep.

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.

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.

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).

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.

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).

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

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

Wow. A five-paragraph I-hate-Perl rant by someone who obviously neither knows the language nor wants to.

Though I probably wouldn't recommend Perl as a first language for everybody either, that's some pretty weak arguments. Appeal to authority of other Perl haters only proves Perl haters exist.

For crying out loud, Perl doesn't have exposed pointers. Perl doesn't prevent the programmer from doing basic parameter checking in functions. Decent REPLs are available for Perl. How could "the Perl REPL" not work with readline if he just said there wasn't a Perl REPL in the previous sentence? Perl doesn't have the same opinion as him as to what sane typing is. Doing stupid stuff results in undefined (to him, at least) behavior. It's possible to implement action-at-a-distance in Perl.

Python and Ruby have their warts too, they're just not exposed in this thread because there's no hater around to quote out-of-context lists of surprising behavior.

Arguing not to learn Perl because the average Perl out there is ugly? Non sequitur. No one with an open mind blah blah blah? I've got opposing data points. (not to mention the true scotsman)

Particularly ironic to quote that MJD text from almost twelve years ago. All of the behavior he described, I can now mostly observe from Python self-appointed champions.

And now on HN as well.

(I'm not saying you have to use Perl. I'm just saying dismissing it for the "reasons" listed in parent post doesn't make sense.)

Reply on news.ycombinator.com