Re^11: Warnings on unused variables?

I have to entirely disagree with you here. I *like* set-and-forget semantics. (I'm actually concerned about mark-and-sweep garbage collection in Perl 6 going toward's Java's non-guarantee of destructor calls, though I don't really know where Perl 6 stands on it.) It means that the compiler will generate code that properly handles resource reclamation, whether that's releasing a database connection (and rolling back any transactions currently underway), or deleting a temporary file (talk about security holes!), or decrementing a lock counter (possibly freeing it). It means that I can't forget to do the cleanup. And I forget a lot.

Missing a "release" on a lock, for example, can lead to deadlock. Missing database connection releases can result in wasted server resources in tracking unfinished transactions, possibly reducing responsiveness on the server. Failing to delete temporary files can result in disk space consumption, often on partitions that are among the smallest partitions on the box if on unix, possibly exposing old data to users that shouldn't see it (though leaving it open to other users for *any* length of time is bad, but auto-delete can reduce the scope of the vulnerability). These can be catastrophic errors. Manually freeing resources that can be freed automatically is just asking for problems. Letting the compiler do it for you is Lazy - in the right way.

Comment on Re^11: Warnings on unused variables?

Replies are listed 'Best First'.
Re^12: Warnings on unused variables? by AZed (Monk) on Sep 28, 2008 at 06:24 UTC
I think you misunderstand me. I also like set-and-forget semantics... at least to function. I would be very unhappy if Perl stopped doing cleanup as scope exited and my screwups resulted in instant malfunctions rather than warnings. I just like to be gently thwapped with a wet noodle when I forget something obvious enough that a compiler can spot it. But I want the language to be only my fallback, because if I stop trying to outperform the automated cleanup, if I stop trying to make sure that I will always, always be able to figure out what I was doing in a chunk of code a year after not looking at it, eventually I am going to come back to code only held together by the automated cleanup and make a mistake too subtle for either me or the compiler to notice. And if I pass that code onto someone else, some year I'm going to download an updated version where someone else made a subtle mistake, or had to rewrite a chunk of it, and wonder if it was my fault. And that's why I want to be able to get warnings on "stylistic" issues. I keep looking for ways to turn on extra warnings without slowing down my main work too much. A lot of what I want can be implemented in subsequent unit tests (and in fact one of the first things I did on my recent project was set up a sample input with a lot of weird things wrong with it and run my code against every time I made a change), but one of the major strengths of a scripting language over a compiled language is the instant feedback from when you did something wrong. I like that. I know there's a culture clash thing going on here, and my approach probably comes off as plodding, paranoid, and clunky to people who have taken code golf and functional programming to a fine art form, but I like to think that one of the things that we can agree on is that (at least as of a week or so ago, when 0.02 of warnings::unused showed up), Perl allows a wide enough range of expression to work for both of us.	[reply]
Re^13: Warnings on unused variables? by SuicideJunkie (Vicar) on Sep 29, 2008 at 17:35 UTC
"stylistic" issues That's the key here, I think. Strictures and Warnings are for things that will break the functionality of your code. If you get a warning, your code probably will not work. Stylistic issues mean that your code works just fine, but somebody thinks it looks ugly. Other people think it looks better. Personal opinions... which is why such things should stay separate from strict/warn, and stay in things like Perl::Critic	[reply]