Possibly I just dont like a compiler telling me how to code

The compiler does that whether you use strict, though! That's why this is not a valid Perl program:

I'd rather debug myself and be better at coding for it

I think that's a rather shortsighted view and a rather lame excuse.

I expect good programmers not to waste their time wanking over manual tasks that the computer is much better at doing reliably. Do you refuse to write automated test suites because you want to demonstrate your mad debugging skills?

Maybe you never make any typos. Maybe you've never spent an hour searching for a problem that doesn't make any sense and finally realized that you wrote $customr when you meant $customer. Since you say, though:

most of my globals are probably unintentional..

I wonder why you wouldn't want something to catch your unintentional errors immediately.

I find it hard to believe that anyone who's written anything longer than Hello, world hasn't been bitten by those errors, and that's why I suggest that refusing to let the computer catch common mistakes is a waste of your time.

Now you're picking holes in my ability to express myself. What I meant of course was, that I don't like the strict pragma telling me I cant use globals, symrefs etc. And not the compiler shouldn't correct non-language constructs.

You're taking things a liiiiiitttle to extremes here, aren't you? I could counter with 'and if you took a programmer, that always used strict, warnings, etc. pp. and gave them a language without these helpers, something to debug, how well would you expect them to do, alongside someone that's always debugged more manually?' - But that'd just be silly.

I like automated tests suites (not written any myself yet though), I wouldn't refuse to. There are always new or unexpected bugs though, even in code that conforms to strict. (As I wrote below, even if the code in itself is perfect, it doesn't mean it does what it's supposed to.)

I make typos, I've spent hours searching for them (privately, and at work in languages which arent as clever as perl), note that 'name used only once', is a 'warnings' error, not one from strict..

That last quote doesn't say anywhere that I think of 'unintentional globals' as errors.

So let me waste my time.. Thats my perrogative, and it's my time, maybe I like wasting it? :)

C.

(I'm wondering if answering this is also wasting my time, I'm not trying to change anyones minds here..)

Well, I will certainly never be the one to suggest that you should use it. I was more interested if there was a technical, as opposed to personal/ideological reason why you chose not to. If your happy, or just happier, without, then that's both your prerogative and good enough for me. My own use of strict is religious, but definitely not Religious. And even if it were the latter, I would never try to 'convert' anyone to it -- there's nothing more annoying in my book:)

From my own perspective, I'm more than happy to allow the computer to take care of as many of the mundane tasks that are involved in programming (and the rest of life) as I can pursuade it to do. That's the essence of programming and computers for me, getting this extremely fast, always willing, supremely dilligent and never forgetful, but essentially dumb assistant to do the stuff that I get bored with. In fact, given the choice there are a whole heap of things that I think that my editor/perl/OS could do for me that they don't (yet).

So I'll stick with my 'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me.' reason.

Sorry but that doesn't really make much sense to me. Why wouldn't you want the compiler to help you out? You can still learn from it. Personally I'd rather do a perl -c myprog.pl and have the compiler complain instead of assuming everything is ok and finding a subtle bug later on.

2 easyish questions..
1. Do *I*? As in, of my own accord? I don't come across that many new programmers that I can think of. I do tend to reccommend warnings, if people are having problems figuring out why their code won't run, because without them perl just tends to die or stop working without saying why. Though most of those are just as easily caught by testing return values of things, like open(). I'm pretty sure I've never reccommended anyone to use strict, unsprisingly, as I don't much myself. Why not? Well it doesn't occur to me as being a way to help them improve. (That's not to say it isn't, just not *my* way.)

2. Having never had an interview for a perl job, I haven't come across this one yet. Being like I am, I'd tell the truth. (And it would be silly to say 'yes of course, all the time', and then get questions about what it would point out in some piece of code, and not know.) I would hope that they would merit me on my coding style and the functionality of it, etc.

The last job interview I had led me to a 'try-out' day, where they gave me some small thingy to programm in VBA, and I'm pretty sure the result could have been robuster, with a lot more checks on input etc, but that wasnt the point, the point was could I take a spec, understand it, and produce some sort of working result. For the rest you need to learn how they work anyway..

Oh, and currently I maintain a 'programm' there, which I didn't write, and doesn't use either warnings or strict.. Even adding warnings gets a page or so of output.. But the darn thing works, perfectly (ok, 99% ,) at a lot of customer sites.. So.. (I would like to improve it, but, no time, the boss says.. )

C.

'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me'

You remembered to backslash the single quote! You must be a master of minor details and you probably never make any typos or bugs. I wish all my coworkers were just like you!

Okay, but I have to do things in the real world. Have pity on me. :-)

"Then I had one too many programs crash from a typo in a variable in an if branch I hadn't tested, and saw the light." -- tilly

"All i know is every time ive turned strict on in my code . . ., ive found errors. and same for other peoples code . . ." -- demerphq

Trust me on this one. You only need to do two things to see the "light." Take a Perl program of more than a few hundred lines, maybe something that you have not touched for a year, and do this:

1. Add "use strict;"
2. Add "my" or "our" to the first time each variable is used. This will shut off most of those warnings that you are getting.

Did you try it? Did you find a couple of misspelled variable names? Are you suprised that you found any? If you didn't find any, now you are sure that the code is perfect.

The general consensus seems to be that without 'strict', you code badly. I don't agree.

Have you ever made a typo in your code? How can you be sure there are none?

most of my globals are probably unintentional

<rant>You'd feel more strongly about this after being forced to work on code that has only global variables, many of which are one letter long. And the code is broken into multiple files. Which all use package main. Thankfully Perl gives you a way to work around this with "my" and/or "local." But it's still bloody sick. Maybe you (not YOU, but the person who did it) know that $j is the filename for the currently selected input file, but nobody else knows that. . .</rant>

Ok, challenge accepted:

-rwxrwxr--    1 cvs      cvs        143437 Oct 20  2002 mappergui.perl
+,v
[download]

This thing has 3500 lines, as you can see by the size.

It took me around 5 minutes to correct all the 'Global symbol' errors, none of which I see as critical, in fact in a GUI app I'd expect the actual GUI itself to be globally accessible. (Which is why I just threw a 'my $Mapper;' in at the top to solve those. I found one, single, misspelled variable name, which didnt surprise me in the least.. (never said I was perfect, or that the thing runs (ran) perfectly.) (Result available, should you want to see it.) BTW: Anything older than that (another year), would be unfair, I've only been using perl that long..

That this now says my code is perfect, is laughable. Unless you just mean the conformity is, it most probably still doesn't work as intended, which would be my definition of perfect.

Yes, I make typos, and I fix them, doesn't everybody? Yes I've also spent hours sometimes looking for stupid ones, that would have probably been shown using strict. I never said it didn't *work*..

As to your rant, probably/possibly. But I haven't yet, so I guess I got lucky. At least, I have some that uses lots of globals in several files, luckily more or less sensibly named. Anyway, I was talking about my preferences for my code, not other peoples. :)

C.

...I found one, single, misspelled variable name..

Which I think proves what bunnyman said.

That this now says my code is perfect, is laughable.

But that's not what it's saying: it's only saying that 'strict' (as it were) couldn't find anything wrong with it. No more no less. The same as when Perl decides your program can be compiled, it is no guarantee that it will run correctly. It only guarantees that it will start to run. If you're lucky, it won't get an execution error before it ends.

Anecdote Alert:
In 1989 I was working on an editor for a system that had its roots in the beginning of the 70's. It used what you would now call a "subfile" system, in which named blocks could contain code and other data.

The maximum size of such a block (which was commonly used as a subroutine) was 8K. Each line consisted of characters followed by a null byte. Once, long before, it was decided that 2 consecutive null bytes would indicate end of data: this saved having to keep the "length" of data somewhere externally. (Remember, in the early 80ies a hard-disk had the size of a dish-washer and was able to store several Megabytes!)

Of course, this posed a problem for empty lines: so an empty line was basically a space with a null byte. So an empty line took 2 characters.

This made the editor quite a bit more complex, but that was of course offset with faster compilation (which was on-demand per subroutine).

While working this new screen-based editor (rather than the line-based editor that it used to be), I found a bug. If a block contained 8191 bytes of code (one less than what could fit in the block), it would still allow you to create a new line. But an empty line took 2 characters! So this would cause an overflow and an execution error.

Unfortunately, I didn't find this problem myself, but my client did. But looking at the code, I realised that that part had basically been lifted from the older version. And lo and behold, that version also contained that error.

The previous version of that editor had been in production more than 7 years at that time. And that editor was based on what had run on the mainframe before that, so it would easily add another 10 years of production to it.

So why didn't anybody find that bug before? Well, since this happened in the editor, you would lose any changes you had made to that block. And I don't know about you, but I'm not able to reproduce code exactly a next time in a create process. So the next time the code would be different and the problem would not occur (you only needed one extra character to be typed to have the block fill up "properly").

I guess this episode taught me that any non-trivial program is never without bugs, no matter how long it has run in production.

It also taught me that you need to create a test-suite: a properly made test-suite would have found this problem immediately. Now, in those days, there were basically no system resources to do this. Current systems do have those resources. And I can only recommend that they be used!

Liz

The general consensus seems to be that without 'strict', you code badly. I don't agree.