I think most people would agree that you should almost always use strict;, and you should almost never use symbolic references.

Many people would also argue that there are times when breaking those two rules may be appropriate. However, the general consensus is usually that you should never use a symbolic reference unless you can first explain why you shouldn't do it. And similarly with strict - if you can first explain why it is so important, then you probably know when it is safe not to use it.

So, I agree completely with Herkum. Learn the rules first, and understand them. And then go ahead and break them :)

Cheers,
Darren

In order to break the rules and improve yourself, one should understand the rules.

Rules should not be there for the sake of the rules, but to accomplish an objective efficiently( well hopefully). A number of people break the rules, including me( especially me) when they don't know any better. Understanding the rules allows one to understand the objective and therefore break the rules when necessary.

Not sure if that was what you were looking for but my opinion on the subject.

Rules should not be there for the sake of the rules, but to accomplish an objective efficiently( well hopefully). A number of people break the rules, including me( especially me) when they don't know any better.

Indeed that's what I've always thought about rules: both in real life and in Programming, with all that's in between those two extremes, they should be there for the people and not the other way round: the people for the rules. I don't want to delve to much into a political/sociological discussion, but that's it: I don't know if a world with no rules at all, or with rules made up by you would be a better one (although as a person with a penchant for libertarian thought I tend to feel like that) but I like to notice that unlike in national authorities, in virtual communities and in programming languages I like (Perl, basically) rules are not there for the sake of being, that is for me to obey them, and they don't get in my way: they're simply out of common sense and they help me along the way.

Something like that sounds like it's far too easy to take out of context and likely miss the entire point.

First, rule-breaking: we've (probably) all heard that goto's are evil. That's a pretty good rule. But you need to understand what's evil about them before you can go and break that rule (which I do regularly, especially in C, and I try to in C++, but some of my coworkers make that difficult).

That said, it's just as likely (from this perspective, not having read that book, or even heard of it) that it's just talking about thinking outside the box. Your boss gives you a box to think in - it's ok to think outside that box for a more holistic solution. I regularly do, and it seems to do me well.

I'ved used goto in C to handle cleanup of dynamically allocated resources.

BOOL some_func() {
   BOOL success = FALSE;

   allocate_temp_resources();

   if (might_fail()) {
      goto Cleanup;
   }

   if (might_fail()) {
      goto Cleanup;
   }

   success = TRUE;

Cleanup:
   free_temp_resources();

   return success;
}
[download]

Suiteable alternatives can be written in C++ and Perl thanks to destructors.

That said, it's just as likely (from this perspective, not having read that book, or even heard of it) that it's just talking about thinking outside the box. Your boss gives you a box to think in - it's ok to think outside that box for a more holistic solution. I regularly do, and it seems to do me well.

Currently I'm so "lucky" that I don't have to work, and even when I did, it was not for a big corporation. But I thought that in those environments this famous lateral thinking was one of the big buzzwords managers use when they want to seem particularly smart, next to "synergy" and "proactive". So, do they want you to think lateral or in a box? (I know that people's mileage will vary!)

The problem with GOTOs are not that they are bad when used responsibly, but it is hard to not use them. In otherwords, they make you lazy.

I have been reading a book called "How to think like Einstein." I have yet to read through half of it, but I have gathered that he was a very notorious rulebreaker, and that contributed greatly to his early successes.

This looks much like as an oversimplification. Historically, special relativity as an early success may be interpreted along the lines you suggest, but it is well known that many many people, including e.g. Henri Poincaré were very near to it. It has been suggested that they didn't publish anything because the hypothesis was so revolutionary back then as to be risky as well, for people with a good academic reputation and that Einstein, on the contrary was working for the patent's office at that time, so in some sense he had nothing to lose.

Perl seems like the natural place for using that way of thinking, so I have come to ask: what are your ways of breaking the rules in learning/doing perl?

I can only quote what others told you in this thread and my personal experience has always been that those who boast about breaking the rules are recognized as freaks by public acclaim. OTOH experienced hackers do so all the time, but in a way that turns out to be more along the lines of "respecting other rules" than "breaking the rules" tout court. In some sense this is what happened with Einstein and special relativity as hinted above: galilean laws of transformation had to be changed because Maxwell's equations are already, intrinsically relativistic, and experimental evidence confirmed them.

Also a genius is a genius (incidentally Einstein, however important his contributions has been, in some respects was somewhat less of a genius than some other scientists of a lesser fame) but most of us are not. Geniuses get it right for themselves, but not quite for everybody, well not always anyway. Donald E. Knuth is a genius too, in fact it's not always easy to put one's hands on stuff created by him...

Then it occured to me: I can just look at the answers when I get to the questions, since it's in a self learning environment. Obviously, in an academic environment, it's too costly to risk, but this is different. That's my tip. What say you, fellow monks?

Well I never learnt Perl through exercises from a book, but rather from problems I had to work hands on for my own needs; OTOH I think that looking at the solutions can be instructive, but I doubt that as a general rule it can be more than trying to think at least a little bit of them on your own first.

There was one time I remember reading the solutions being helpful at all, it was in precalculus (don't remember the book) and the book didn't have a separate solutions manual, instead every exercise was given with a purpose (no raw drill) and the solutions page in the back wasn't just what the right answer was, but what you should have learned and noticed in working the problem. Each page had the general admonision at the top "If you found the answer but not the reason, work it again."