Hacker Newsnew | comments | ask | jobs | submitlogin
Perl tutorials suck (and cause serious damage) (perl.org)
128 points by Mithaldu 902 days ago | comments


steve8918 902 days ago | link

I appreciate the author's honesty.

To be perfectly honest myself, the last time I looked at Perl was about 4 years ago, and I despised the experience. I used it for about 10 months because the company I worked at had their entire infrastructure running on it, but it was the worst code I had ever seen, so I quit. If I remember correctly the code that broke the camel's back for me (pun intended) was:

$a = $src[$src];

I've forgotten my Perl syntax so the syntax may be incorrect, but essentially what happened was that the original author had defined two different variables with the name "src", one being a scalar variable and the other being an array, and apparently those have two different namespaces.

So when I looked at the perl tutorial that the author points out, it looked like regular perl to me. However, if the syntax of Perl has changed since 2007, then I'd be willing to give it a shot. Although I've recently started learning Python, and I'm enjoying it, except for the dynamic typing and the GIL... which is a rant for another time.

-----

sreque 902 days ago | link

I had the exact same experience coding Perl in my last company. I found myself, just like Steve Yegge says in his ancient languages blog post, having to memorize all the special edge case rules and idioms of the language just to get anything done. Whenever I got to choose Python, Ruby, or C for a task I felt like I was breathing fresh air again after being stuck in a musty room for a while.

I remember being offered to choose any toolset I wanted for a particular project and finding out that Perl was the only scripting language that had the bindings to the C libraries I needed to use. Naturally, I decided to to do the whole project in straight C instead. :)

The funny thing is, whenever I would code in Perl for a while, I would actually grow acclimated to it. I would start to think to myself, "Hey! I'm finally getting things done. I CAN be productive in this language!" It was only after switching away to another language again that I would re-recognize just how painful Perl really is. This experience actually repeated itself multiple times for me as I moved on and off Perl projects and it helped me learn to sympathize more with others who are perfectly content to code in Perl for a living.

At one point, I had enough and began recording all the weird Perlisms that were wasting my time as I encountered them. My goal was to compile a "95 theses against Perl" document and post it on my manager's door as a joke. Fortunately, I only got into the 40s before my manager offered to let me move to another team where I never had to write a line of Perl again in that job!

It's possible to write good Perl just like it's possible to write good COBOL, and better tutorials would definitely help newcomers to the language do just that. I would rather spend my time writing good code in other languages, however.

-----

mikecaron 902 days ago | link

So here's the thing, Larry Wall is not only a programmer, he is a linguist. That's reflected in the myriad of ways that one can write something in Perl, reflected in the common refrain at YAPCs the world over, "TMTOWTDI" (There's More Than One Way To Do It). But because of the flexibility Larry designed into the language, there's also "more than one way to do it" ...wrong (ok, not "wrong", but so complicated and whacky that Joe programmer 10 years from now wouldn't have a clue about). But this very flexibility gives Perl a unique beauty.

I don't think it's the language's fault that poor code exists to teach people the way to Perl zen. It's more that scripting languages themselves lend to one-offs and poor code writing, especially in the days of early Perl, when people were giddy to get their hands on something that wasn't as ugly as "sh". We need better programmers who are not "too busy to write good code" as well as better material.

-----

danssig 902 days ago | link

This line of reasoning is old and tired. Natural language is a bad enough way to communicate with people, it's a ridiculous way to communicate with machines which take everything literally and treat everything implied to mean "crash in amusing and unforeseeable ways".

One of perl's big "natural language" claims is that things mean something different in different context. I think there are several movies based on what can happen when two people have a conversation but have a context mismatch.

-----

mikecaron 902 days ago | link

I'm not saying it's good or bad, all I'm saying is that it was Larry's choice when developing the language.

Here's a great example of C++ meaning different things in different contexts. How about this:

    int *& p;
    *&p;

-----

danssig 902 days ago | link

One is a declaration, one is an expression. And, believe me, I taught C++ for a while and this already causes a lot of confusion.

-----

danssig 902 days ago | link

Seriously?! Someone downvoted this statement? It was completely factually true. People do indeed get confused by the difference between declarations and expressions. That's why some languages don't like to have that distinction.

With things like this I would like to advocate that Perl be treated as politics: something that's just not appropriate for HN. The thing is, when ever perl comes up some of us point out why we don't use it anymore but perl fans get seriously emotional about perl and start downvoting things they disagree with (much more so than ordinarily happens). I really suspect that if it weren't for the downvote limit some perl fan would have gone through and downvoted all my posts by now.

-----

berntb 902 days ago | link

If you want to see sensitive, there are other language communities you should troll instead...

-----

kamaal 902 days ago | link

Huh,

The problem is not whether Perl or C++ is bad. All languages have their own use cases. When their use cases go away, nobody feels the need to use the language. That's the golden rule for any language/tool that exists out there.

Perl, C++ and even lisp even over a half a century are still alive out there because there are use cases that those languages serve very well. And a majority of the people feel compelled to use them. The reason why people troll is they feel they can convince others not to use the language they hate.

C++ has a lot of problems, but compared to the other languages advantages it offers are many and it doesn't quite really have good competitors in those areas. We can go and talk about various other languages that you can compare with C++. But language itself is nothing. The surrounding ecosystem, libraries, books, help, availability of programmers, the total weight of the community with their combined wisdom over the years. In all those parameters, syntactical problems of a language count for very little things in the real world. There are more than sufficient real world scenarios out there where C++ has done the job exceedingly well.

I have myself maintained large C++ applications. And have faced many problem like what others have mentioned before. But given our efficiency requirements, Java wouldn't last for an hour in our production environments. And given all the conditions I mentioned, there isn't really a clear alternative apart from C++. And I'm sure vast majority of the C++ project have the same reasons to use C++.

Perl has its own niche. I don't really have time to write 100 line of Java/Python code with piles of exceptions of handling code just to read a file. I don't have time or the patience to deal with alien integration of Regular expression that Python offers. Python has other problems, It never evolved as a rapid scripting language, I still can't consider using python as a prototyping language. It has a little posh gloss to it. Python has nothing even remotely closer to CPAN. Compared to Perl, Python is no where in syntactical flexibility. Perl's documentation is just awesome, support for newbies is too good. And they seem to fixing all the problems in the new language Perl 6. I use scripting for rapid tasks which need urgent attentions. Some of that gets converted to production work. If that rapid aspect is missing I don't really consider that language a scripting language. And serious scripting language will have to provide means of easily modifying data of all kinds text especially. And also provide seamless integration with the Operating system.

Python never provided me all this. Its never could become my primary scripting language.

But I appreciate Python's other use cases. It has some awesome frameworks. And it has a very easy verbose syntax. And I'm sure it has plenty of use cases for people around.

Now just because you like Python, don't go on endlessly trolling Perl. This has a been going for a decade now and is getting a little boring. Both language have their use cases and are likely to be there for a real long time. Whether you like it or not.

As Bjarne Stroustrup mentions in his "The C++ programming lanaguage" - You must learn C++ not for a new syntax to do old things, but to build better systems.

-----

danssig 902 days ago | link

I don't use Python, Ruby or any other scripting language unless someone pays me to. I was simply responding to inaccurate or tautological statements thrown around in this thread.

-----

berntb 902 days ago | link

Huh?

I commented on a bad troll that wrote 10++% of all comments and made sweeping personal attacks.

I assume you wanted to comment on the same comment as me? :-)

-----

kamaal 902 days ago | link

:)

Yes, I think by mistake I hit the wrong reply button.

-----

vorg 902 days ago | link

> Natural language is a bad enough way to communicate with people

If it was bad, it wouldn't have become the way to communicate with people in every culture on the planet. Don't forget "natural language" can include body language, as well as words, grammar, idioms, stresses, pause, and intonations.

> there are several movies based on what can happen when two people have a conversation but have a context mismatch

Matching context using protocols such as small talk before a main topic of conversation is also part of natural language. Many of us who work on computers don't learn these other aspects of natural language very well, and tend to project this limited command of natural language onto computer languages.

-----

quanticle 888 days ago | link

>If it was bad, it wouldn't have become the way to communicate with people in every culture on the planet.

That's because the vast majority of social situations are very tolerant of misunderstandings and have lots of redundancy/repetition to ensure that communication occurs successfully.

In cases where misunderstandings can be significant, we turn to more formal modes of communication. Scientific literature, technical manuals, and legal documents are all more stilted than regular prose for the simple reason that they need to clearly and unambiguously communicate their contents. Reader enjoyment is a secondary consideration.

Programming languages need to be even clearer than legal or technical documents, because they're being read by a machine rather than another person. As such, I see ambiguity in programming languages as even more of a sin than ambiguity in contracts and scientific papers.

-----

danssig 902 days ago | link

>If it was bad, it wouldn't have become the way to communicate with people in every culture on the planet.

We have nothing better, but it is not the only way we communicate. Mathmatics made a whole other language to communicate with because spoken language wasn't effective enough.

Further, natural language is useful among people because we can work out meanings, fill in implicit statements closely enough, have experience on what certain phrases mean and so on. Even with every tool we have, we often still get it wrong. So if it takes so much intelligence to be able to communicate with written language, why would anyone imagine it a good idea to expect computers to be able to do this too? A computer must explicitly be told what to do in every situation. Typically when we need to go into that level of detail with people we don't use natural language either. We generally demonstrate what must be done (e.g. youtube tutorials which often don't even have sound, etc.).

>Many of us who work on computers don't learn these other aspects of natural language very well, and tend to project this limited command of natural language onto computer languages.

Is that a rock thrown at me? I don't think I have a problem here. I'm just realistic about what language is good at. Natural language's value is that it can be very concise when everyone has the same context as you. With a computer this is never the case.

-----

kristaps 902 days ago | link

Do you still have that list? I think it could be very useful to someone who has to dive into a legacy Perl codebase.

-----

hercynium 902 days ago | link

Two excellent books I can recommend for someone working with legacy Perl:

Perl Medic (Peter J. Scott) - http://amzn.com/0201795264 Effective Perl Programming (Joseph N. Hall, Joshua A. McAdams, brian d foy) - http://amzn.com/0321496949

Besides those, having a good reference to the language is also essential. For example, I keep Perl In a Nutshell close by, even though I almost always just search http://perldoc.perl.org/ when I need that info.

-----

sreque 902 days ago | link

I wish I had kept it, but I can't seem to find it in the set of files I kept from that job. It would have been fun to make a blog post out of it.

-----

flounder 902 days ago | link

Googling for "things I hate about Perl" turns up a number of articles -- often written by folks who like Perl 5 but who also are happy to admit to its issues.

-----

steve-howard 902 days ago | link

Yeah, the sigils indicate a sort of namespace (@ for array, $ for scalar, & for function), but that breaks down because when dereferencing an array, the @ becomes $. I have a fair amount of experience with Perl and I still had to read your explanation to remember how that could be valid.

In the company I worked for that used Perl extensively, there were coding standards. In fact, you don't even need that, you just need to remind everyone that cleverness is not a goal in writing maintainable software, even if cleverness is what Perl's best at.

-----

skimbrel 902 days ago | link

They weren't originally intended to provide namespacing, as far as I know. They were there to make the compiler's life easier.

The reason that an array subscript is "$foo[0]" is because the $ sigil means "HEY COMPILER, the expression here is going to evaluate to some scalar".

@foo is the entire list and the compiler treats it as a list type; $foo[0] is an element of the list and needs storage/behavior of a scalar. Same thing for hashes: %bar is the whole hash; $bar{quux} is an element and must be treated by the compiler as a scalar.

The programmer must remember that square braces mean array subscript and curly braces mean hash lookup.

So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler. It's overhead that probably isn't needed in the modern age, but we're effectively stuck with it. It wouldn't be so bad if they hadn't made the second (and IMO worse) decision:

You can reuse symbols across contexts. The way this works is that the compiler maintains a symbol table where each symbol has a slot available for each of the types (scalar $, array @, hash %, subroutine &). This was originally the way to emulate pass-by-reference: you'd write a subroutine that assigned its arguments into typeglobs (* foo — think of it as a wildcard for all things named foo that behaves as a magic scalar with the contents of foo's symbol table entry) and then pulled them back out as the types it wanted:

  local(*foo) = @_;
  foreach $bar (@foo) {
    do_something($bar);
  }
This amounts to telling the compiler "I want to alias the name foo in all contexts to my argument, and then go look at what's stored in the array at that name" and is a poor man's pass-by-reference.

Perl 5 has a real reference system that completely obviates the need for this, except for the case of monkey-patching a subroutine, where you still say:

  local *Package::quux = sub { ... }"
What's left is an unfortunate case where things like the GP mentioned ($bar = $foo[$foo]) are possible, and people who think they're being clever will do these things. Like the parent said, this is not a good thing to do.

-----

Jeema3000 902 days ago | link

"So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler."

I'm not entirely sure that's correct. I think Larry Wall (being a linguist originally) designed it that way because he thought that using context-sensitive sigils was more like regular speech where leading words indicate the number, i.e. 'a cup' vs. 'some cups'...

-----

epochwolf 902 days ago | link

> Larry Wall (being a linguist originally)

Having taken a class on linguistics, I have to say basing a computer language on it is a horrible idea.

Human languages are far more complex and verbose than is required for talking to computers. Consider that it takes years to master a spoken language. A computer language should be much easier to pick up once you already know how to use an existing language. Computer languages should attempt to reduce complexity and verbosity where possible.

Example: I picked up lua in a week. (javascript and ruby experience helped a lot) I'm not an expert by any means but I'm capable of writing usable applications. I doubt a person could pick up a new human language in a week.

-----

mkn 902 days ago | link

Human languages are far more complex and verbose than is required for talking to computers.

This is mostly a quibble, but human languages are not more verbose than computer languages, generally. I can generally rely on you to allocate all the variables and present the result in a context-aware way when I ask you, "What is 3 + 5?" I'd generally have to allocate variables and tell the computer where to put the result if I were to ask it the same question.

What was, and still is, sort of magical about Perl is the degree to which it is aware of context and can use it to sort out meaning. If anything, the chief complaints against Perl, which stems from its similarity to natural languages (!), is its terseness and expressive power, these complaints being that it's indistinguishable from line noise and is a write-only language.

-----

Mithaldu 902 days ago | link

Honestly, Perl is really anything but a write-only language. Consider this:

https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...

It should be unparsable, but most people who have some Perl knowledge find they can actually read and understand this.

-----

steve-howard 902 days ago | link

I appreciate the depth of your response; the original reasoning makes sense, and as Python 3 tells us, it is very hard to get people to use your new version if you break enough old code.

-----

danudey 902 days ago | link

This seems unfair to Python 3. The Python community, including the developers of Python 3, have not been encouraging people to migrate to Python 3. In fact, it was never in their roadmap for people to migrate immediately. The common wisdom has always been 'When starting a new project from scratch, if all the libraries you need are ported, and you won't need backwards compatibility down the road, then use Python 3. Otherwise, use Python 2.x'.

It's quite difficult to get people to use your new version when you actively tell them that it's probably not a good idea right now.

-----

kgtm 902 days ago | link

Perl is really powerful, and with power comes responsibility. Reference handling is an area that needs great care, as you can easily make subtle mistakes. Coding standards are important in a code base, often there are many ways to accomplish the same thing. Usually some forms are cleaner than others and can be enforced. An example regarding dereferencing:

  use v5.10;
  use strict;
  use warnings;
  
  my $ref = ['one', 2, 3];
  say $ref;
  
  foreach (@{$ref}) {
  	say;
  }

  # These are the same. The first form is much cleaner.
  # It also makes more sense semanticaly
  say @{$ref}->[0];
  say @{$ref}[0];
  say $ref->[0];

-----

qntm 902 days ago | link

You're proving your own point about the subtlety of reference handling and the important of coding standards in Perl. Was that intentional?

    say @{$ref}->[0];
This raises a deprecation warning for me.

    say @{$ref}[0];
This is technically correct, as the leading sigil "@" indicates you are returning an array, but since you're only returning one element in that array, this should probably be "${$ref}[0]" which returns a scalar only.

    say $ref->[0];  
This the only form which I would consider correct or "clean".

This example proves nothing about Perl's power, though. The fact that difficult and fiddly reference handling shenanigans are necessary to handle something as trivial as nested arrays and hashes shows quite the opposite.

-----

kgtm 902 days ago | link

Absolutely! Running the code under Strawberry (5.12.3) produces no warnings and "works" as one would expect. Can it be any easier to shoot yourself in the foot? Regardless, Perl has a special place in my heart.

-----

chromatic 902 days ago | link

... since you're only returning one element in that array, this should probably be "${$ref}[0]" which returns a scalar only.

It's perfectly fine to use the array sigil, in which case it's a one-element list instead of a scalar. That's useful sometimes.

-----

danssig 902 days ago | link

>Perl is really powerful,

Compared to what? C? In what way is it more powerful than Ruby, Python, Ocaml, Haskell, etc.?

There are things perl has over e.g. python (lambdas) but there are at least as many things those languages have over perl (e.g. python generators built in) and all of those languages are easier to use. Look at the code you wrote there! I assume "use v5.10" is actually a forward compatibility declaration instead of a backward one, right? Really embarrassing if so.

-----

Mithaldu 902 days ago | link

When Larry left for Perl 6 everyone figured that would be it for Perl 5 and then a few years later when Perl 6 kept not being viable for more than toy use the p5p was forced to figure out ways of extending Perl 5 without breaking old code. That was one of the ideas. This is what is more current planning in that regard:

http://www.youtube.com/watch?v=yJss-l2XuV8

-----

sciurus 902 days ago | link

It's the equivalent of "use feature qw(switch say state)". "use feature" allows "new syntactic constructs, or new semantic meanings to older constructs" to be enabled in the current scope.

http://search.cpan.org/~flora/perl/lib/feature.pm

-----

mikecaron 902 days ago | link

Some years ago, Damien Conway spoke about changing sigils going away in Perl 6... whenever that comes out... perhaps 2030.

-----

cygx 902 days ago | link

Perl6 already is out - there's a Tetris-implementation using GTK for Niecza, a Perl6 implementation on Mono/.NET. The implementations are not feature-complete, but if that's your sole criterion, then neither C nor C++ are out yet.

The most feature-complete implementation - Rakudo on Parrot - is not production-ready, though, and currently somewhat stalled due to low bus factor: The object-system refactor (which made things like natively-typed attributes possible) introduced a lot of regressions, and the regex engine in particular is not yet fixed as the lead-developer was hit by real-life issues.

-----

chromatic 902 days ago | link

The implementations are not feature-complete, but if that's your sole criterion, then neither C nor C++ are out yet.

That's a little disingenuous. I'm a Perl fan and I'd like to use Perl 6 practically, but the fact that someone wrote a Tetris clone in one of multiple incomplete implementations of Perl 6 doesn't mean that Perl 6 is actually useful for much.

-----

cygx 902 days ago | link

That's a little disingenuous.

Not really. It just shows that feature-completeness may be a good metric when comparing implementations of the same language, but not so much when comparing them to implementations of a different language.

the fact that someone wrote a Tetris clone in one of multiple incomplete implementations of Perl 6 doesn't mean that Perl 6 is actually useful for much

The fact that there's a Tetris-clone in Perl6 indeed doesn't mean much. However, the fact that it uses GTK is an example of CLR interop, which opens up a whole new level of practical applicability.

-----

waqf 902 days ago | link

Perl 6 changes this syntax to @src[$src], effectively admitting that the way sigils worked through Perl 5 was a failed experiment.

-----

vetler 902 days ago | link

Also, $a is a global variable within the current package, which means that if you don't have to declare it, even if strict is turned on.

-----

greglindahl 902 days ago | link

$a and $b are special due to their use in sort functions. This is a wart that predates "my".

Newer languages have warts, too, you just don't know what they are, yet.

-----

alex_c 902 days ago | link

Documentation rot is one of the most annoying things when trying to learn a new technology, and the fault lies mostly with Google. "Definitive" sources sometimes instantly become obsolete when a new version of a technology is released - and sometimes they don't. Sometimes they very clearly indicate which version they apply to, often they don't - if you're new to a technology you're unlikely to be aware of the difference.

The real problem is that "relevance" for technical resources has a very different meaning from "relevance" on the Internet at large, because the content pages and incoming links, by themselves, don't contain all the necessary information to judge whether a page is still relevant. As a result, Google is in some ways less and less useful as a programmer's tool - not because Google is getting worse, but because there are more and more layers of obsolete information out there.

-----

mcantor 902 days ago | link

> As a result, Google is in some ways less and less useful as a programmer's tool - not because Google is getting worse, but because there are more and more layers of obsolete information out there.

This is bloody brilliant.

-----

ChuckMcM 902 days ago | link

Its got a name, information white out, and can occur for a number of reasons. The example I use is finding information on Steve Jobs from 2000 - 2005 is nearly impossible on Google because the first 50 - 100 results of the query 'Steve Jobs' is filled with eulogies and references to his death.

But news worthy events are only one form of white out, historical weight is another (as the perl example shows).

Disclaimer I work at blekko.com (a search engine) which allows you to specify things like /date=2005 in the search providing semantic intent. Searching through white-out situations is one of the uses of the slashtag system.

-----

majika 902 days ago | link

Thanks for the disclaimer. Your post is propaganda.

Finding information on Steve Jobs from 2000 - 2005 is actually pretty easy on Google. Search "steve jobs", then on the left-hand bar, click "custom range," and input 2000 to 2005. Done.

I invite readers to actually try the blekko example to see how incapable it is. Searching with /date=2005 : (a) sorts the results by date, such that you the first few pages are full of irrelevant pages from Dec 31, 2005. And, (b) only returns results from 2005 (it's not clear how to search over a time range).

-----

Mithaldu 902 days ago | link

This is a nice theory, but Google manages to keep step if new material is produced. Gabor Szabo's tutorial series is really very new, but is the fourth result. The problem is that there is not enough up-to-date material connected with the term "perl tutorial".

-----

alex_c 902 days ago | link

Yes and no. I obviously don't know that many details about Google's ranking algorithms, but content age and incoming links play a big role. This plays against content freshness and rate at which new incoming links are added.

I suspect Google uses more or less the same algorithm for general content and for tech documentation. The difference is, general content - news, discussions, fiction, etc. - rarely loses relevancy, it can only be supplanted by newer, more relevant content over time.

This happens for documentation, but it takes time - and at any given time you end up with a hodgepodge of content for various versions.

There's also no foolproof way to search for content for a specific version - this would go a long way towards fixing the problem. The closest solution is restricting the search results by date, I often have to do that.

-----

prodigal_erik 902 days ago | link

> Another option would be to reach out to the maintainers of those sites and convince them to take down their sites or at the very least add links that prominently point to more modern content.

Not only should advocating link rot as the preferred solution alarm any web user, but there are people out there who specifically need to learn Perl 4 to maintain or port crappy old systems (they might even outnumber people selecting Perl 6 or 5 for new projects), and we shouldn't throw their tutorials down the memory hole to make the language look more sane. Stick with a notice that better dialects are available, please.

-----

jleader 902 days ago | link

I seriously doubt there are more people maintaining code in Perl 4 than there are starting new projects in Perl 5 or Perl 6. Perl 5 replaced Perl 4 in 1993. I personally know of several companies using Perl 5 when they start new projects; I think my last exposure to Perl 4 in production was around 1995.

On the larger subject, I agree, old documentation shouldn't be discarded, but should be clearly marked as referring to an older version. Of course, the horrible outdated examples the original article mentions have such disclaimers, but people still see their code as representative Perl code.

-----

pwaring 902 days ago | link

It's not a tutorial as such, but the Modern Perl book is up to date:

http://www.onyxneon.com/books/modern_perl/

Unfortunately you can't create your own set of tutorials from it, and it doesn't rank highly in Google.

-----

npongratz 902 days ago | link

Modern Perl's author, chromatic, offers some pretty good advice on how to learn Perl:

http://www.modernperlbooks.com/mt/2011/09/how-to-learn-perl....

-----

zura 902 days ago | link

I'd also recommend the Higher-Order Perl book:

http://hop.perl.plover.com/book/

-----

Mithaldu 902 days ago | link

It's a good book, but i don't think it's good for newbies. Some parts of it still go over my head. :D

-----

gtani 902 days ago | link

Effective Perl is also terrific. I spent a lot of time reading first edition.

One of the problems is Google won't let you filter for tutorials from last, say 2 years. There's lots of solid tutorials for 5.10 and up

-----

pwaring 902 days ago | link

Google will let you filter searches by date, it's there under the More Search Tools -> Custom Range option. If I choose Last Year, I don't see most of the Perl 4 stuff.

The problem is that people looking for a basic Perl tutorial may not know about all the filtering options.

-----

Mithaldu 902 days ago | link

You're right in that it is not the right search, but as i said on Reddit about this:

What people should search for is immaterial. For us in the perl community, only what people do search for counts.

-----

majika 902 days ago | link

It's one hell of an ugly link, but:

http://www.google.com.au/search?q=perl+tutorial&ie=utf-8...

-----

Mithaldu 902 days ago | link

I'm aware of Modern Perl and recommend it for every novice, but as you mention, it is not a tutorial and thus doesn't have much to do with what the average newbie is looking for. It's also not readable on the web.

-----

pwaring 902 days ago | link

There's a HTML version available (the build scripts are available on GitHub), so it could be readable on the web.

-----

Mithaldu 902 days ago | link

I'm sure chromatic will read this at some point. Wonder what he thinks about setting it up as a proper website.

-----

chromatic 902 days ago | link

If I produce a second edition, we will publish the HTML online as a proper website.

-----

Mithaldu 902 days ago | link

Oh well. Better than nothing i guess. :)

-----

chromatic 902 days ago | link

Give me a couple of weeks. You may hear a pleasant announcement.

-----

Mithaldu 902 days ago | link

Cheers. For what it's worth: My main concern in this is that any kind of widely-used perl tutorial needs to inherently updatable by a wide group of people. Modern Perl would make the cut because it's hosted in Git and a website could easily be generated from there in regular intervals.

-----

gatlin 902 days ago | link

There is a subset of Perl one can get a sense of by reading the Camel book in order which is sane, readable, and effective. If you read Wall's explanations and justifications you get a great mental model on top of which the "weird" stuff makes sense and feels even natural.

Most criticisms I read focus on how dealing with legacy Perl is typically bad because it was written poorly. The thing is, I've read legacy PHP, legacy Python, and other "legacy" code that was just as terrible.

The new Perl code I work with, though, written by my colleagues, is every bit as elegant and readable as code in any other language - provided thoughtful people are writing it.

Perl has a bad rep but I have yet to see a single legitimate argument thrown at it which doesn't boil down to "I read some bad legacy code." I've been in the same boat, and believe me, I sympathize :)

-----

nickolai 902 days ago | link

In this particular case it is also google's fault for turning up results of such dubious freshness( blekko for examople gives perl.org as first result - which looks better to me)

So as weird as it sounds, Google shares the blame for the poor perl code being written.

-----

snorkel 902 days ago | link

Unfortunately Perl coding culture includes a few deeply entrenched bad habits such as using horribly short variable names, overuse of the default variable, and using regex when a simpler string match would suffice. These subtle bad habits make typical perl code hard to follow and thus reflect badly on the language itself.

-----

hapless 902 days ago | link

That's not really a current concern for the perl community. That was true 15 years ago.

Lots of 15-year-old code is out there on the internet for folks to sneer at.

-----

sliverstorm 902 days ago | link

In my opinion, the fact that 15-year-old code is floating about and still relevant should be something to appreciate.

-----

grout 902 days ago | link

For some people, though, any use of the default variable is overuse. Nothing to be done about that whine.

-----

snorkel 902 days ago | link

IMHO it's OK to use $_ in small scope contexts, like in a tight loop, but very offensive when $_ refers to an operation that occurred three pages back.

-----

grout 902 days ago | link

Perl culture has largely moved from static pages to blogs and Twitter, and Google doesn't do well in that situation. Disclosure: I work for a competing search engine. But that's why I know.

-----

billturner 902 days ago | link

I think Perl could use something like "Learn Perl The Hard Way." The foundation for the tutorial/book is already there: http://learncodethehardway.org/

-----

mmuro 902 days ago | link

This isn't a problem with the tutorials. It's a problem with the freshness of those tutorials.

If you are really worried about this, write a blog post (or several) that show people how to properly code Perl.

-----

keithpeter 902 days ago | link

Agreed, but this is part of a much wider problem with the currency of pages that have a high search engine rank.

Try searching for information about an obscure problem with (say) Linux. The pages found often relate to earlier versions of the OS and even in some cases 2.4.xx kernels. You have to know a bit to be able to filter the search for newer releases.

-----

Mithaldu 902 days ago | link

I tried to keep the title short and attention-grabbing. Note how one of my solutions basically say: "We need to write a perl clone of Python Tutorials."

Also, more importantly, this task is so huge that a single person trying to solve it on their own is doomed. It needs to be a community thing.

-----

st0p 902 days ago | link

The situation for PHP is just as bad, try googling for php mysql tutorial... The first five results are all using oldskool mysql_connect like back in the day. This is deprecated in php 5.4 and much better alternatives exist nowadays. Definitly a bad situation for any language IMHO.

-----

alttag 902 days ago | link

This suggests a different alternative exists: re-branding Perl (or PHP) as Perl6 (or PHP5), and consistently using those terms within the community to distinguish the two. Make a point that it is a different language, enforce the usage (via style guide) in all public facing commentary.

It will take time, but the community will start to change, and thus actually change what users are searching for.

Think of HTML/CSS. One gets a more relevant set of results by searching HTML5, because there was a great deal of effort put into explaining how the language had changed. When looking for bleeding-edge features, a search for CSS3 is more helpful than a search on CSS (which like the perl situation, sometimes returns legacy garbage). The same applies when trying to troubleshoot a problem on OS X: adding 'lion' to the query often improves relevance of results.

I short, make a conscious effort to create a new label and inject it into the public consciousness.

-----

danssig 902 days ago | link

Or you could, you know, do what other languages do and just move on to perl 6. It was meant to replace perl 5 after all. To be honest, as a outsider this whole movement of keeping perl 5 around forever after perl 6 is getting closer and closer to usable is one of the most bizarre, cultish things I've ever seen in the tech community (and that's saying a lot).

-----

alttag 902 days ago | link

I don't see how your post is a response to mine.

My point was that OP complains they can't change what users are searching for. I assert they can, but they have to change the way they market and talk about their language. They need to present it as markedly different and give users a way to differentiate it in search from previous versions.

(Aside: I don't use Perl. I don't want to use Perl. The things I need to get done I can accomplish in other languages, and that are clear when I look at the code six months later.)

-----

Mithaldu 902 days ago | link

Oh man, i should've seen this post before i answered to your other one. You're either a magnificent troll or are just commenting on things you have barely a passing knowledge of. Do you also wait for Perl 6 because it will make all Perl code 5 times faster like the recruiter at that Berlin company i visited?

-----

danssig 902 days ago | link

I coded in perl for an agonizing 5 years. Sure, it made sense to start working on perl 5 again once it was clear that perl 6 was stalled but is that still the case? I was under the impression that there are just a few things missing. If that's so then I would say people should be getting prepared for migration.

You can resist it, as has happened in various communities (i.e. python) but to actually compete with perl 6 and try and make the two different languages is down-right cult behavior. Perl isn't a person, it doesn't have feelings. If you tell it "screw you perl 5, perl 6 is better" it's not going to cry or leave angry messages on your phone. It's just a tool.

-----

Mithaldu 902 days ago | link

First and foremost: There is no way to "move on" from Perl 5 to Perl 6. Perl 6 is a completely different language at this point and more akin to what Ruby tried to be, back when it was made, in respect to Perl 5.

And well, with the pace Perl 6 is moving on it'll be another decade for it to become production-usable. There may be only 5% of the feature-set missing (maybe more, maybe less, i don't keep track), but those 5% are the hardest part, and then comes the task of making all that run fast and to bundle it up, etc. etc. I wouldn't hold my breath. Also see chromatic's writings on that matter:

http://www.modernperlbooks.com/cgi-bin/mt/mt-search.cgi?blog...

http://www.modernperlbooks.com/mt/2011/08/why-my-side-projec...

-----

danssig 902 days ago | link

Well, fair enough if that's the case but I wish the perl community would be consistent. Anytime someone jokes about perl 6 not being usable, someone (often chromatic!) comes out and says "it's usable now, you're talking nonsense".

And if it's truly a different language then you should change the name. Racket did it. And then you would have room to eventually have a version 6 of perl (what you call perl5 now).

-----

Mithaldu 902 days ago | link

Quite a few people want to change its name, but Larry doesn't want to and short of kidnapping him and tieing him up in a basement with some sketchy figures in robes and bandanas there's not much we can do on that front.

And well, it is usable as in, you can write software with it. It's just not commercially usable or complete.

-----

va_coder 902 days ago | link

Isn't that the Perl culture? As someone who has seen a lot of Perl code, I'm serious.

-----

mchanson 902 days ago | link

I think there are two very different sides to perl culture. About ten years ago I worked on a OO Perl project which was ~10k lines. It had coding standards, test suites, documentation, and was easy to maintain and bring new engineers into.

The other side is hacked together scripts. Which have their place, but are often a mess.

-----

Mithaldu 902 days ago | link

Actually, there is a name for both sides:

There is the CPAN, which is obviously what it is;

And there is the DarkPAN, a term describing all the internal projects in companies, or small tools hacked together by people who don't know or care about the CPAN.

-----

jpdoctor 902 days ago | link

> or small tools hacked together by people who don't know or care about the CPAN.

In some parts, the latter is referred to as BedPAN.

-----

Mithaldu 902 days ago | link

I'd like to answer, but the question is a bit vague. What are you referring to with "that"?

-----

mgkimsal 902 days ago | link

I took "that" to mean "hard to read / cryptic code".

-----

Mithaldu 902 days ago | link

That is by far not the norm for code written nowadays by CPAN authors who are aware of advances in the art. Have as an example the code in the very first module featured on frepan.org at the moment: https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/M...

-----

w0utert 902 days ago | link

Well, that code starts out with the following procedure:

====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8

BEGIN {

    # Turn on the debugger's symbol source tracing
    $^P |= 0x10;
 
    # Work around bug in pre-5.8.7 perl where turning on $^P
    # causes caller() to be confused about eval {}'s in the stack.
    # (See http://rt.perl.org/rt3/Ticket/Display.html?id=35059 for more info.)
    eval 'sub DB::sub' if $] < 5.008007;
}

====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8

As someone with a 2-digit number of years of experience in 4 different programming and casual experience with about 4 others, I couldn't for the life of me have figure out what that code does, if some hadn't commented it.

The rest of the code looks a bit like PHP by the way, except uglier (not trying to flame here, just my opinion).

Maybe some day someone will be able to explain why anyone in their right mind would voluntarily choose to program in Perl, if not because of prior experience with the language, or some form of religious beliefs. The 'look at the xyz CPAN modules!' argument doesn't really cut it for me.

-----

bad_user 902 days ago | link

BEGIN is a hook that gets executed when you first load the file, before any other code in that file.

From http://perldoc.perl.org/perlvar.html ...

    $^P |= 0x10 ... debugging support, 
        keeps info about source 
        lines on which a subroutine is defined
The third line of code is a workaround for a bug, documented in the comment above it.

If you were Chinese, would you complain that English words have no meaning to you?

    The 'look at the xyz CPAN modules!' argument 
    doesn't really cut it for me.
The libraries available are the most important asset of a language, more important than the language itself.

Example: I just chose Ruby instead of Python for a project and I just discovered that there's nothing like PIL for doing image processing in Ruby. The alternatives are so bad that I'm thinking about rewriting the whole thing in Python.

As far as CPAN is concerned, it's a really big (maybe the biggest), really comprehensive, centralized repository of libraries.

CPAN also has something that RubyGems / the Python Index or the Maven repositories do not ... http://cpantesters.org/

-----

w0utert 902 days ago | link

I think you are missing the point here. I'm not saying Perl is hard or impossible to program, or that it is 'bad' or anything, just that Perl code very often comes out obfuscated and hard to interpret, even for someone who knows many other programming languages.

Example: instead of '$^P |= 0x10', something along the lines of 'sys.debug = True' is a lot easier to read, right? Perl code is full of such examples, I could make up at least 20 examples from the module linked to before in this thread, all using alternatives resembling different other languages, and all much easier to interpret.

The problem with Perl (as far as I can judge) is that it tries to cram too many different things into operators and magic variables, and that it allows too much wonky stuff that might come in handy to shave off a few characters if you are a guru, but could just as well have been left out, sacrificing compactness for readability. Another thing that Perl seems to lack is orthogonality, I always get the impression that the language allows you to solve the same problem in 10 different ways.

Just to give a counter-example, take a look at Objective-C code, which is almost the antithesis of Perl. It's almost self-documenting because of the naming conventions, named parameters, the way the frameworks are designed, etc. Sure, it's about 10 times more verbose than Perl, and the core language probably has 10 times less features, but if you have a good editor and don't try to obsessively do things 'your way' instead of 'the Objective-C way', it's a joy to work with.

If you spend enough time in the Perl world, of course you'll get used to the language features and syntax of the language, and forget about how long it took to get to that point. At that point it's probably a perfectly fine and powerful language that allows very fast development.

> The libraries available are the most important asset of a language, more important than the language itself

100% agreed, but most other popular languages also have huge libraries (core SDK libraries or third-party). At some point you reach some kind of critical mass where you can solve 99% of the problems using native libraries, leaving only 1% that requires bindings to e.g. C/C++, shell exec, RPC, etc. Most other languages already reached that point or make it easy enough to interface with other languages that have more libraries, to the extent lack of libraries is not an issue anymore (such as Objective-C, for example).

-----

qntm 902 days ago | link

> Another thing that Perl seems to lack is orthogonality, I always get the impression that the language allows you to solve the same problem in 10 different ways.

This is a deliberate feature of Perl, whose motto is "There's More Than One Way To Do It".

Not to defend the practice, since the fact that there are 10 ways to do something means that (1) there's a 90% chance that when you look at somebody else's code you can't understand it, unless you learned all 10 ways and (2) at least 50% of those ways are objectively worse than the alternatives, but people will still use them because Perl programmers are encouraged to solve problems in whatever way they can.

Contrast with Python, where "There should be one - and preferably only one - obvious way to do it".

-----

bad_user 902 days ago | link

For the rationale behind it, read this article by Larry Wall ... http://www.wall.org/~larry/pm.html (really, it's one of the best language-related essays around).

     Contrast with Python, where "There should be 
     one - and preferably only one - obvious way to
     do it".
As a Python developer myself, I call that bullshit ... how about 2 urllibs in the standard library, both broken and a dozen or so XML parsers and I still have to install PyQuery to remain sane.

Also, its one obvious way to do it also breaks down in the language itself, like there's still a difference between old-style and new-style classes. And because the language does not have anonymous code-blocks (something which Perl has), the language designers added a bunch of features to take care of certain use-cases, features which are not orthogonal, like lambda expressions, foreach blocks, with blocks, iterators AND decorators, all of which could have been avoided by adding just a simple feature.

If you ever try building a simple DSL, something that modifies a class at runtime, you'll have about a dozen or so techniques to use, but none of them as beautiful as ActiveRecord ... which relies on the fact that a class block in ruby is just syntactic sugar for opening a class context with define_class and passing it a code block.

-----

qntm 902 days ago | link

I know more about Perl than I do about Python so I can't comment on Python's execution of its chosen philosophy, but I certainly prefer it as a philosophy of programming language design.

-----

Natsu 902 days ago | link

> Example: instead of '$^P |= 0x10', something along the lines of 'sys.debug = True' is a lot easier to read, right?

That's what we have use English for.

http://perldoc.perl.org/English.html

-----

whazzmaster 902 days ago | link

Ruby does indeed have continuous testing for major (and even not-so-major) gems at http://travis-ci.org/.

I'm not quibbling with the rest of your response; just wanted to shout-out Travis since I learned of it myself recently.

-----

Mithaldu 902 days ago | link

cpantesters is not continuous testing, it's distributed testing across all possible combinations of hardware, os and perl versions. :)

-----

petercooper 902 days ago | link

I just discovered that there's nothing like PIL for doing image processing in Ruby.

Isn't RMagick "like" PIL?

-----

bad_user 901 days ago | link

No, it isn't.

RMagick is a leaky, slow and unmaintained piece of software. It is also used only for small retouching on images, the primary use-case being to make thumbnails. PIL on the other hand is more reliable and can do things that RMagick does not, like actual drawings or to put it another way, whatever you can do with GDK, you can do with PIL, all in one nice package.

PIL is not perfect either, but there's nothing like it for Ruby.

-----

petercooper 901 days ago | link

I can't argue about it not getting much love in the updates department and its instability under many configurations (though sometimes you can get lucky ;-)), but..

and can do things that RMagick does not, like actual drawings

RMagick has a SVG-related drawing system called RVG:

http://studio.imagemagick.org/RMagick/doc/rvgtut.html

As well as a smorgasbord of drawing primitives:

http://studio.imagemagick.org/RMagick/doc/draw.html

-----

Mithaldu 902 days ago | link

Literally the only hard part there are the magic variables, which one can look up easily as long as one knows that they're all listed under `perldoc perlvar`. (Though i'd like to mention that he should've used `use English;`.)

Either way, my point still stands. I took an entirely random and fresh piece of code and aside from one tiny well-documented bit, all of it is easily readable and most importantly: Extremely different from the code example used in that study.

The rest of your comment does not merit discussion because you've your prejudices and are content with them.

-----

w0utert 902 days ago | link

> Literally the only hard part there are the magic variables [..]

Sure, I'm not even saying that stuff like this makes Perl 'hard', just obscure and in many cases obfuscated. I have no idea whether you could write non-trivial Perl code that doesn't use magic variables or weird operators, but every piece of Perl code I have ever had to read or debug/maintain has suggested it's an integral aspect of the language. Maybe I've just been unlucky so far...

The code you linked to contains lots of other weird and obscure stuff by the way, I just picked the first routine to make my point. To illustrate it in another way: I challenge anyone who doesn't know anything about Perl to explain why there is another block labelled 'BEGIN' at the end of the module, which goes like this, and what it is needed for:

==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8

    no strict 'refs';
    foreach my $sym ( sort keys %{ __PACKAGE__ . '::' } ) {
        next
            if $sym eq
            'VERSION';   
        my $code = __PACKAGE__->can($sym) or next;
        delete ${ __PACKAGE__ . '::' }{$sym};
        *$sym = sub { goto &$code };
    }
==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8

Imagine having to come up with this if you are new to Perl programming :-S

> The rest of your comment does not merit discussion because you've your prejudices and are content with them

That's funny, I hear the exact same thing every time I ask someone about what makes Perl great, and how it stands out from any other language. Somehow I never get a real answer, just accusations of being prejudiced or anti-Perl.

I'm not against any programming language (except maybe VB ;-), I'm just curious why Perl is still relevant for anything except legacy code, now that we have so many nice languages for almost every problem domain.

-----

Mithaldu 902 days ago | link

> I challenge anyone who doesn't know anything about Perl

Now that premise in itself is silly and you know it. (I could get a code sample for any language that would be impossible to understand by someone who doesn't know anything about tha language and it wouldn't even have to be a complicated one.)

> I'm just curious why Perl is still relevant for anything except legacy code

Few languages are as evolvable as Perl. Nowadays Perl has a better object system than Ruby and the only hard part is getting it into the core.

Also, i should probably point out that i got a tad unlucky in that the first example i grabbed was meant to do some fairly language-integral stuff, namely reloading all the libraries already loaded into memory: https://metacpan.org/module/Module::Refresh

-----

danssig 902 days ago | link

>Now that premise in itself is silly and you know it. (I could get a code sample for any language that would be impossible to understand by someone who doesn't know anything about tha language and it wouldn't even have to be a complicated one.)

The difference, and reason his statement is relevant, is that perl is one of the easiest languages to find these kinds of examples for. Where there is smoke, etc.

>Few languages are as evolvable as Perl.

[citation needed] Are you aware of what is being done in other languages. Does perl run on the JVM yet?

>Nowadays Perl has a better object system than Ruby

This is a subjective statement, right? If not, I'm afraid I'm going to have to ask for citations again.

>and the only hard part is getting it into the core

Oh, right. So as a new programmer I'm going to have to dig around to figure out how to pull things in to make the language modern after I've already gone through the trouble of getting it setup? I saw a "modern best practices use recommendation" one time. There were like 25 or so (I'm not even joking) use statements at the top of the file. If you give me 25 lines to pull stuff in I could probably make BF usable.

-----

Mithaldu 902 days ago | link

> The difference, and reason his statement is relevant, is that perl is one of the easiest languages to find these kinds of examples for. Where there is smoke, etc.

Entirely by virtue of there existing a bulk of legacy software. Most other dynamic languages do not even have an appreciable amount of legacy software.

If i were to restrict myself to searching only the past 5 years of produced Perl code on CPAN i would be hard-pressed to find truly terrible samples.

Either way you managed to entirely miss the point that for a person with no knowledge about a language (including no knowledge about sibling languages), any example of source would be nearly impossible to understand at first try.

> [citation needed] Are you aware of what is being done in other languages. Does perl run on the JVM yet?

I said language, not virtual machine.

> I'm afraid I'm going to have to ask for citations again.

When does Ruby plan to have Roles?

> I've already gone through the trouble of getting it setup

Hahahaha. Trouble setting up perl, good one, pal. Also, i know what sample you saw once. That was written as a joke. It is a boilerplate tchrist made to demonstrate what would be necessary to make scripts entirely and absolutely perfect with unicode. (Note: Perl's default state is still better in handling unicode than most other languages.)

> So as a new programmer I'm going to have to dig around

Right now, yes. Which is why i wrote the blog post mentioned above. How kind of you to notice.

-----

danssig 902 days ago | link

>If i were to restrict myself to searching only the past 5 years of produced Perl code on CPAN i would be hard-pressed to find truly terrible samples.

Well, it depends on what you mean by "truly terrible samples". If you mean "things the thread-OP couldn't understand" then I would be surprised if your statement is correct. Was the example he provided from CPAN?

>I said language, not virtual machine.

People are doing "crazy" things in every language. Including porting them to the JVM so they can use the whole body of Java libraries (which is more than what's on CPAN btw).

>When does Ruby plan to have Roles?

I'm not a ruby guy but ruby has mixins which fill the same niche (even if they probably behave a little differently to accomplish it).

>Trouble setting up perl, good one, pal.

It depends. If I'm on a modern Linux, sure, if it's not already there I can apt-get it. That's not always the case though.

>That was written as a joke

I'm pretty sure the one I saw from Chromatic. It had various Moose stuff in it as well. Surely you don't have to pull in the whole OO framework to get unicode to work?

>Right now, yes. Which is why i wrote the blog post mentioned above. How kind of you to notice.

So finally you accept a criticism. But only the one you made yourself already. And they say Rails is a ghetto...

-----

Mithaldu 902 days ago | link

> Was the example he provided from CPAN?

Man, please, you could at least read the whole thing. I provided the sample, randomly pulled from CPAN and that dude harped on one small extract.

> mixins

Hm, gonna have to admit i have no clue about those. Will read up at some point.

> It depends. If I'm on a modern Linux, sure, if it's not already there I can apt-get it. That's not always the case though.

Perl is on every linux, no exception. It may not be the newest one, but even then you can use perlbrew to install whatever version you want for your own user account. But seriously, perl is on every linux.

And even on windows it's as stupidly simple as downloading an installer and clicking 5 times.

> moose ... boilerplate

You wouldn't include Moose in a boilerplate thing.

> criticism

I work daily with Perl, i've considered MANY criticisms, i have a whole book of criticisms of my own. The problem you're running into is that i've already spent a hell of a lot more time thinking about those criticisms than you have.

-----

danssig 902 days ago | link

>I provided the sample, randomly pulled from CPAN and that dude harped on one small extract.

I missed that part. But I find it highly amusing that you randomly pulled a sample file from CPAN an already failed your own test.

>Hm, gonna have to admit i have no clue about those. Will read up at some point.

Fair enough, but I feel compelled to point out that you've been harping on me all over this thread for not reading things yet you declare perl's OO (bolted on via a library, no less) superior to ruby's without even knowing how ruby's works.

>Perl is on every linux

Linux yes. Not every Unix, not every Windows.

>You wouldn't include Moose in a boilerplate thing.

It was. It was a boilerplate list of things one should use to make perl a modern language. I think they wanted to make one module that did all these uses for you so you could just use that, but the point remains. It takes a lot of modification to stock perl to bring it up to the level of the competition.

>The problem you're running into is that i've already spent a hell of a lot more time thinking about those criticisms than you have.

I worked daily with perl for half a decade. I can believe that you have spent more time thinking about the criticism because you apparently like perl. I had no emotional attachment to it so when I saw languages that didn't have those problems I left it and never looked back.

-----

jleader 902 days ago | link

>>Perl is on every linux

>Linux yes. Not every Unix, not every Windows.

Wait, you'll only consider languages that come pre-installed on all Unices and Windows? That's a pretty short list!

Or are you complaining that Perl isn't available for some Unices or some versions of Windows? I'm curious to know what version of Unix or Windows has Python and/or Ruby interpreters available, but doesn't have Perl.

-----

danssig 902 days ago | link

No, you've completely misunderstood my post. I was saying "I have to do all the effort to install perl and then I still have to do more work to actually write a program". We then took a detour where it was claimed there is no effort involved in installing perl. Well, sometimes there is. There is with other languages too, but at least once I have them installed I can just use them without having to go read about about current use statements I should be using.

-----

Mithaldu 902 days ago | link

> I missed that part. But I find it highly amusing that you randomly pulled a sample file from CPAN an already failed your own test.

And on that note i'll concede defeat to your lack of reading comprehension.

-----

chromatic 902 days ago | link

I'm not a ruby guy but ruby has mixins which fill the same niche (even if they probably behave a little differently to accomplish it).

Mixins don't even compare to roles; mixins in Ruby (at least Ruby 1.8 this was true) manipulate inheritance, and so they suffer from ordering problems. The compiler can't warn you about collisions and conflicts.

Roles solve that problem.

-----

danssig 902 days ago | link

>Mixins don't even compare to roles;

Of course they do. They may not be as good as perl's Roles but you can't say "Ruby doesn't even have a way to do this" as the GP did (paraphrased). They do, perhaps it's not as nice but it's there.

-----

chromatic 902 days ago | link

One of the explicit design goals for roles was to solve the flaws of mixins. We succeeded. While it may be technically correct to object to a hyperliteral interpretation of an English idiom, I stand by the assertion that the presence of roles in Perl 5's Moose and Perl 6's object system makes for a better object system than Ruby with mixins.

-----

gizzlon 902 days ago | link

Most of the ugly code can be avoided nowadays.. but for special cases (as that one) and a few not-so-special cases, the code can get ugly. At least until you get used to it ;) Also, perl is very flexible which is a good thing. But for better or for worse, perl lets people do crazy things.

Actually, that flexibility is one great things about perl. If you know what you are doing, you can adapt the style for the purpose. For example, hack together something fast, and if it looks like a viable solution, flesh it out into something more maintainable. This is true for other languages as well, but IMHO, even more so for perl.

-----

danssig 902 days ago | link

>perl is very flexible which is a good thing.

So are nearly all modern languages. No advantage.

>perl lets people do crazy things

So do nearly all modern languages. No advantage.

When ever I hear people sing the praises of perl it just always make me think most haven't really sat down and learn many other languages. It's like hearing an English speaker say something like "man, English is so great because you can... like, express yourself in it! And there are even lots of ways to express yourself in it! And you can express all kinds of stuff!". Great, so it's like all the other languages then?

-----

gizzlon 902 days ago | link

So do nearly all modern languages. No advantage.

Didn't you read my last sentence?

When ever I hear people sing the praises of perl it just always make me think most haven't really sat down and learn many other languages.

Obviously not true.. But I agree most people probably know one language better than the rest, and I also think that when people praise language X ;)

(oh, and for what it's worth, I think i started with both python & ruby before perl)

-----

pronoiac 902 days ago | link

Those lines are making my phone attempt widescreen, badly. Could you edit?

-----

mgkimsal 902 days ago | link

There's different things being discussed here at this point.

You're saying "CPAN authors don't write crappy code". Fair point, but CPAN authors aren't looking for tutorials, nor are they writing tutorials (otherwise, they'd be tutorial authors, not CPAN authors).

The original point was that googling for tutorials brings up old crappy code. What modern perl experts write has no bearing on this issue.

What's needed is an concerted effort to have those talented CPAN authors focus their efforts on writing modern tutorials, publicizing them, getting linked, and also contacting owners of older tutorials and asking them to link to the modern stuff.

It won't happen overnight, but there's a cyclical downward spiral with perl that needs to be stopped. People looking at old/bad perl tutorials may never get to the point where they even learn about or use CPAN in the first place, and won't get exposed to better techniques. Many tutorials in other languages are bad, of course, but compare a bad PHP tutorial to a bad perl one, and the PHP will still be easier for newbs to grok.

-----

Mithaldu 902 days ago | link

Let me just point out that i wrote the linked blog post. :)

I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.

-----

cube13 902 days ago | link

>I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.

Unfortunately, I'm not sure if this is going to help all that much at this point. I think the main group of people that use the current, rather poor tutorials are newbie(or even experienced) developers that have inherited Perl code that uses the language in a way that they have never encountered before. Those devs need a good way to find all the insane single character typing optimizations built into the language.

If you have a script that consists of one 1500 character line with approximately 10 alphanumeric characters total, well written Perl examples aren't going to help you figure it out that much.

Sure, it will help if you're a complete newbie to Perl, and learning it from scratch. For those people, drilling good coding standards into them from day 1 is a GREAT thing, if for no other reason than to avoid the spaghetti that plagues a lot of Perl.

-----

More



Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: